Transaction processing method and system in inter-chip interconnection scenario and chip

Abstract

This application relates to the semiconductor field and provides a transaction processing method, system, and chip in an inter-chip interconnection scenario. The method includes: receiving a target transaction sent via a second interface proxy; allocating a request processing entry to the target transaction and forwarding it to a first home node; after receiving a completion response and having already sent the completion response to a second chip, sending a first completion confirmation message to the first home node before receiving an actual completion confirmation message; identifying associated transactions upon receiving a subsequent consistency maintenance request and suspending the corresponding request; and updating the request processing entry and unsuspending it upon receiving an actual completion confirmation message to ensure transaction order and improve resource turnover efficiency.

Description

Technical Field

[0001] This application relates to the semiconductor field, and more specifically to a transaction processing method, system, and chip in a chip-to-chip interconnection scenario. Background Technology

[0002] As computing systems demand increasing computing power, memory access bandwidth, and storage capacity, multi-chip interconnect systems are widely used in high-performance computing, artificial intelligence processing, server processors, and heterogeneous computing. These systems typically connect multiple chips via high-speed inter-chip links, enabling processing units, cache units, or storage control units on different chips to access resources on remote chips.

[0003] To ensure consistency in accessing shared data, multi-chip interconnect systems typically employ cached consistency protocols. Taking the AMBA CHI type consistency protocol as an example, the system includes requesting nodes, home nodes, and proxy nodes located at the inter-chip interface. Requesting nodes initiate consistency transactions, home nodes manage the address space and maintain the transaction processing order, and proxy nodes handle requests, responses, and status forwarding between the on-chip protocol and the inter-chip transport protocol.

[0004] In some consistency transactions, after the home node returns a completion response, the requesting node also needs to return a completion confirmation message. The home node typically releases transaction tracking resources, sorting resources, or buffer resources upon receiving the confirmation. When the requesting node and the home node are located on different chips, this completion confirmation message needs to be returned across the inter-chip link, adding inter-chip round-trip delay to the completion confirmation process. This increases the time the home node occupies resources, impacting transaction turnaround efficiency and system throughput. Furthermore, completion confirmation may also be related to the order control of subsequent consistency transactions. If the timing of completion confirmation processing does not match the actual transaction completion timing of the remote requesting node, it may cause deviations in the observation order between subsequent stalking requests or consistency maintenance requests and preceding transactions, affecting the transaction order required by the consistency protocol. Summary of the Invention

[0005] This application provides a transaction processing method, system, and chip for inter-chip interconnection scenarios, which can reduce the impact of cross-chip round trips for confirmation on resource release and transaction turnaround efficiency in multi-chip interconnection systems, and avoid disrupting the cross-chip consistent transaction processing order.

[0006] In a first aspect, embodiments of this application provide a transaction processing method in a chip-to-chip interconnection scenario. The method is applied to a first interface proxy in a first chip, the first chip further including a first home node, and a second chip including a second interface proxy and a second request node. The method includes: Receive the target transaction sent via the second interface proxy, allocate a request processing entry to the target transaction, and forward the target transaction to the first home node; After receiving the completion response from the first home node and having already sent the completion response to the second chip, if no actual completion confirmation message is received from the second chip, a first completion confirmation message is sent to the first home node. Upon receiving a subsequent consistency maintenance request from the first home node, the request processing entries are matched based on the address information and target source node identifier of the subsequent consistency maintenance request to identify whether there are any associated transactions that have sent the first completion confirmation message but have not yet received the actual completion confirmation message. When the associated transaction is identified, the subsequent consistency maintenance request is suspended, and the request processing entry index corresponding to the associated transaction is recorded to prevent the subsequent consistency maintenance request from being sent to the second chip during the suspension period. Upon receiving the actual completion confirmation message returned by the second chip, the corresponding request processing entry is updated according to the transaction identifier, and the pending state of the corresponding subsequent consistency maintenance request is released according to the updated request processing entry index, so that the subsequent consistency maintenance request can be re-entered for transmission.

[0007] Secondly, embodiments of this application provide a transaction processing system in a chip-to-chip interconnection scenario, comprising a first chip and a second chip; wherein... The second interface proxy of the second chip is configured to send the target transaction initiated by the second requesting node to the first interface proxy, and forward the completion response returned by the first interface proxy to the second requesting node; The first interface agent of the first chip is configured to receive the target transaction sent through the second interface agent, allocate a request processing entry for the target transaction, and forward the target transaction to the first home node; after receiving the completion response returned by the first home node and having sent a completion response to the second interface agent, if no actual completion confirmation message is received from the second chip, a first completion confirmation message is sent to the first home node. The first home node of the first chip is configured to process the target transaction and return a completion response, as well as issue subsequent consistency maintenance requests during subsequent processing. The second request node of the second chip is configured to return an actual completion confirmation message to the first interface agent after receiving the completion response; The first interface proxy is also configured to, upon receiving a subsequent consistency maintenance request from the first home node, match the request processing entries based on the address information and target source node identifier of the subsequent consistency maintenance request to identify whether there are any associated transactions that have sent a first completion confirmation message but have not yet received an actual completion confirmation message; when an associated transaction is identified, the subsequent consistency maintenance request is written into the consistency maintenance processing tracker and set to suspension, and the index of the request processing entry corresponding to the associated transaction is recorded; when an actual completion confirmation message is received, the corresponding request processing entry is updated according to the transaction identifier, and the suspension state of the corresponding subsequent consistency maintenance request is released according to the updated request processing entry index, so that the subsequent consistency maintenance request can be re-entered for transmission.

[0008] The transaction processing system in the aforementioned chip-to-chip interconnection scenario has the function of implementing the transaction processing method corresponding to the chip-to-chip interconnection scenario provided in the first aspect above. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned function, and these modules can be software and / or hardware.

[0009] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform a transaction processing method in a chip interconnect scenario as described in the first aspect.

[0010] Fourthly, embodiments of this application provide a computing device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the transaction processing method in the chip interconnect scenario described in the first aspect.

[0011] Fifthly, embodiments of this application provide a chip including a processor coupled to a transceiver, for executing the transaction processing method in an inter-chip interconnection scenario provided in the first aspect of this application. In one possible design, the chip can also be a dedicated hardware structure for implementing the technical solution provided in the first aspect above.

[0012] In a sixth aspect, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a computer, cause the computer to execute the transaction processing method in the chip interconnection scenario provided in the first aspect.

[0013] Compared to existing technologies, in this embodiment, after receiving the completion response from the first home node and sending the completion response to the second chip, the first interface proxy in the first chip can send a first completion confirmation message to the first home node without waiting for the second chip to return an actual completion confirmation message. This decouples the local transaction completion from the cross-chip completion confirmation round trip, shortens the time the first home node occupies transaction tracking resources, sorting resources, or buffer resources, and improves resource turnover efficiency and system throughput performance. Furthermore, when the first home node issues a subsequent consistency maintenance request, the first interface proxy matches the request processing entries based on the address information and target source node identifier of the subsequent consistency maintenance request to identify whether there are related transactions that have sent a first completion confirmation message in advance but have not yet received an actual completion confirmation message. For the identified related transactions, the corresponding subsequent consistency maintenance request is not immediately sent, but first enters a suspended state. After receiving the actual completion confirmation message, the corresponding request processing entry is updated according to the transaction identifier and the suspension is lifted, so that the subsequent consistency maintenance request can be re-entered for transmission. Therefore, the embodiments of this application do not simply complete the confirmation in advance, but rather, while releasing local resources in advance, accurately identify, selectively suspend, and release subsequent consistency maintenance requests that may affect the consistency order. This ensures that the processing order of related transactions within the same request node and the same cache line is not disrupted, preventing subsequent snooping requests or other consistency maintenance requests from arriving at the peer node before the corresponding transaction is actually completed. Thus, the embodiments of this application can, while maintaining protocol compatibility and consistency correctness, simultaneously optimize local completion latency, reduce resource consumption, improve transaction throughput, and reliably maintain the cross-chip consistency transaction processing order. Attached Figure Description

[0014] The objectives, features, and advantages of the embodiments of this application will become readily understood by referring to the accompanying drawings and reading the detailed description of the embodiments.

[0015] Figure 1 A schematic diagram illustrating the processing flow of a transaction with the ExpCompAck attribute; Figure 2 This is a flowchart illustrating a transaction processing method in a chip interconnection scenario according to an embodiment of this application. Figure 3 This is a schematic diagram of the process in which the first interface proxy returns the first completion confirmation message in advance on the CHIP2CHIP receiving side in an embodiment of this application; Figure 4 This is a flowchart illustrating the Snoop-CompAck adventure scenario in an embodiment of this application. Figure 5 This is a flowchart illustrating the multiple Snoop-CompAck adventure scenarios in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of a transaction processing device in the context of chip-to-chip interconnection according to an embodiment of this application. Detailed Implementation

[0016] As computing systems continue to expand in scale, single-chip solutions are increasingly unable to meet the application demands of high-performance computing, artificial intelligence inference, server processors, and heterogeneous computing scenarios in terms of computing power, on-chip cache capacity, and storage resource expansion capabilities. To overcome the limitations of single-chip resources, multi-chip interconnect systems have been widely adopted. These systems connect multiple chips through high-speed serial links, enabling one chip to access the memory or cache resources on another chip, thereby achieving greater computing power and storage capacity at the system level.

[0017] In multi-chip interconnect systems, a cached consistency protocol is typically used to ensure consistency in access to shared data across multiple nodes. Taking the AMBA CHI protocol as an example, two types of logic are usually deployed at the inter-chip interface: a sending-side proxy and a receiving-side proxy. The sending-side proxy (RA) converts intra-chip transactions into inter-chip transmission requests and sends them to the peer. The receiving-side proxy (HA) receives requests from the peer, converts these requests into intra-chip protocol transactions, and forwards them to the local home node (HN) for processing. Based on this, the peer requesting node (RN), the peer RA, the local HA, and the local HN together constitute a complete processing path for cross-chip consistency transactions.

[0018] In the CHI protocol, for transactions with the ExpCompAck attribute, after the home node HN returns a completion response Comp or CompData, the requesting node RN also needs to return a completion acknowledgment message CompAck. This CompAck indicates that the requesting node has received the aforementioned completion response and also serves as an important basis for the home node to determine that the transaction is completed at the protocol level. Typically, the home node considers the corresponding transaction complete only after receiving the CompAck, and then releases transaction tracking resources, sorting resources, or related buffer resources. Simultaneously, upon receiving the CompAck, the home node can also assume that the corresponding requesting node has stably observed the relevant data, thus enabling it to continue initiating subsequent consistency maintenance operations on the same cache line, such as sending a Snoop request to the requesting node.

[0019] like Figure 1As shown, in a cross-chip scenario, the typical processing flow of a transaction with the ExpCompAck attribute includes: the peer RN initiates a request, the peer RA forwards the request to the local HA, and the local HA then forwards the request to the local HN; after processing, the local HN returns Comp or CompData to the local HA, and the local HA then forwards the completion response to the peer RN via the peer RA; after receiving the completion response, the peer RN generates a CompAck, which is then returned to the local HN via the peer RA and the local HA. Therefore, the return process of CompAck requires a complete cross-chip round trip.

[0020] However, inter-chip links typically involve encapsulation / decapsulation, link scheduling, physical layer transmission, and protocol adaptation, resulting in higher latency than on-chip interconnects. Therefore, under existing standard procedures, the completion time of a transaction at the local node (HN) is strongly coupled with the time it takes for the peer node (RN) to return a CompAck. Before the CompAck actually returns to the local HN, the local HN must continuously retain the corresponding sorting and tracking resources, which cannot be released in a timely manner. For read-intensive or latency-sensitive workloads, this serial waiting introduced by cross-chip round trips directly limits the transaction throughput and resource turnover efficiency of the local node.

[0021] On the other hand, if the local HA simply returns a CompAck to the local HN before receiving the actual CompAck from the peer, while this can shorten the waiting time for the local transaction to complete, it introduces new ordering risks. Specifically, after receiving the early-returned CompAck, the local HN might assume that the peer RN has already completed observing the relevant transaction results and then initiate a subsequent Snoop request for the same cache line. However, the corresponding transaction on the peer RN may not actually be completed yet. If this subsequent Snoop arrives at the peer RN first, it will disrupt the order between subsequent consistency maintenance operations and the confirmation of previous transactions, thus violating the CHI protocol's requirements for the order of consistent transactions.

[0022] Therefore, in existing technologies, directly adopting the standard CompAck return process results in the local transaction completion delay being constrained by the cross-chip link latency, making it difficult to decouple local resource release from peer confirmation. On the other hand, simply adopting an early CompAck return method may cause order violations between subsequent Snoops and the completion confirmation of preceding transactions. How to reduce the impact of cross-chip CompAck round trips on local resource release and transaction turnaround efficiency while ensuring that the cross-chip consistent transaction processing order is not disrupted has become a pressing technical problem to be solved in this field.

[0023] To address the aforementioned technical issues, this application proposes a transaction processing method, system, and chip for chip-to-chip interconnection scenarios.

[0024] The solutions provided in this application relate to multi-chip interconnect communication and cache consistency maintenance scenarios, particularly to a mechanism for optimizing the processing of completion confirmation messages in inter-chip transaction processing based on a consistency interconnect protocol. To facilitate understanding of these embodiments, several key concepts and device scenarios are explained below. In a multi-chip interconnect system, different chips can be interconnected via high-speed serial links, enabling a processing unit, cache unit, or storage control unit in one chip to access target resources in another chip. To ensure data consistency during cross-chip access, a consistency interconnect protocol, such as a CHI-type protocol, can be used in the system. This type of protocol typically involves a requesting node, a home node, and a proxy node located at the inter-chip interface. The requesting node initiates read / write transactions or other consistency transactions. The home node manages the target address space and maintains the serialized processing order of consistency transactions. The proxy node performs transaction conversion, request forwarding, response forwarding, and state maintenance between the on-chip protocol and the inter-chip transmission protocol. These embodiments are primarily applicable to device scenarios where a receiving-side proxy at the inter-chip interface receives, forwards, and confirms transactions from the peer chip; they can also be applied to scenarios where a sending-side proxy cooperates to complete cross-chip transaction interactions. Furthermore, the completion response, completion confirmation message, and subsequent consistency maintenance request described in the embodiments of this application can correspond to the completion-type response, completion confirmation-type handshake message, and probe-type maintenance message in the consistency protocol, respectively, but are not limited to a specific naming method.

[0025] The chips involved in the embodiments of this application can be various integrated circuit chips with cache-coherent interconnect requirements, such as central processing unit chips, graphics processing unit chips, artificial intelligence accelerator chips, data processing chips, server processor chips, system-on-a-chip chips, heterogeneous computing chips, in-memory computing chips, or other functional chips with inter-chip coherent access capabilities. They can also be multi-chip packaged systems, chiplet systems, or other processing systems formed by inter-chip link coupling composed of the above-mentioned chips. In some embodiments, the chip can integrate a processor core, cache, memory controller, interconnect control unit, and inter-chip interface unit. In other embodiments, the chip can also exist as a dedicated control chip or interconnect control chip; as long as it can participate in cross-chip coherent transaction processing, the solutions provided in the embodiments of this application are applicable.

[0026] Reference Figure 2 , Figure 2This is a flowchart illustrating a transaction processing method in an inter-chip interconnection scenario provided by an embodiment of this application. The method can be executed by a first interface proxy in a first chip and can be applied to a multi-chip interconnection system for consistent transaction processing. It reduces the impact of cross-chip round trips for confirmation on local resource release and transaction turnaround efficiency, and avoids disrupting the cross-chip consistent transaction processing order. The first chip also includes a first home node, and the second chip includes a second interface proxy and a second request node.

[0027] In this embodiment, CHIP2CHIP is a multi-chip interconnection method where multiple chips are connected via a high-speed serial link to form a unified, collaborative processing system. This allows processing units, cache units, or storage control units in one chip to access target resources in another chip, thereby overcoming the limitations of a single chip in terms of computing power, cache capacity, and storage expansion. To ensure data consistency during cross-chip access, the system can employ the CHI (AMBACoherent Hub Interface) protocol. CHI defines the consistency transaction processing between the requesting node and the home node, including request initiation, completion response, completion confirmation, and subsequent consistency maintenance.

[0028] In this multi-chip interconnect system, the first interface proxy corresponds to the HA (Receiver Proxy). The HA receives transaction requests from the peer chip and converts them into transactions under its own internal bus protocol. It then forwards these transactions to the local home node for processing, acting as a proxy for the remote requesting node. After processing by the local home node, the HA also returns the corresponding completion response to the peer chip and tracks the acknowledgments and subsequent consistency maintenance related to the transaction. The second interface proxy corresponds to the RA (Sender Proxy). The RA converts transactions generated within its own chip into inter-chip transmission requests and sends them to the peer HA. It also receives the completion response from the peer and sends back the protocol handshake messages related to the transaction. Thus, the HA and RA are deployed in pairs, located on the request receiving side and the request sending side respectively, together forming a complete inter-chip transaction processing link.

[0029] The first home node can correspond to the HN. The HN is a node in the consensus protocol used to manage the home of the target address space and maintain consistent serialization points. It is responsible for home point processing of the target transaction and returning a completion response. The second requesting node can correspond to the RN. The RN is the node that initiates a consistency transaction. It can initiate read transactions, write transactions, or other consistency transactions. After receiving the completion response from the HN, it can also send back a completion confirmation message based on the transaction attributes.

[0030] In the CHI protocol, Comp or CompData is a completion response, indicating that the home node has completed the transaction at the home node. CompData can also carry data back to the requesting node. CompAck is a completion acknowledgment message, indicating that the requesting node has received the completion response. For transactions with the ExpCompAck attribute, the requesting node needs to return CompAck after receiving Comp or CompData. This CompAck indicates that the requesting node has received the transaction completion result and also serves as an important basis for the home node to determine that the transaction is completed at the protocol level and to initiate subsequent consistency maintenance operations.

[0031] Furthermore, Snoop requests are also involved in the consistency maintenance process. A Snoop is a query, snooping, or invalidation request initiated by the home node to the requesting node to maintain cache consistency, used to confirm or adjust the requesting node's status for a specific cache line. In this embodiment, subsequent consistency maintenance requests may be, for example, Snoop requests. To support cross-chip transaction status tracking and control, the system can also set up RHT and SHT. RHT is a request processing tracker used to create an entry for each read / write transaction received from the peer, recording whether the transaction needs to return a completion acknowledgment, whether a completion response has been sent to the peer, whether a completion response has been received from the local end, and whether a true completion acknowledgment has been received from the peer. SHT is a Snoop processing tracker used to create an entry for each Snoop request from the local HN, recording the Snoop's pending status, associated transaction entry index, and other information to control whether subsequent consistency maintenance requests can be sent out.

[0032] In some implementations, for ease of description, the completion acknowledgment request status, completion response sending status, completion response receiving status, and actual completion acknowledgment receiving status in RHT can be denoted as EXPCOMPACK, SENTC2CCOMP, RCVDCHICOMP, and RCVDC2CCOMPACK, respectively; correspondingly, the hazard flag and associated transaction entry index field in SHT can be denoted as SNPCOMPACKHAZ and SNPCOMPACKHAZ_RHTENTRY, respectively.

[0033] Specifically, EXPCOMPACK indicates whether the current target transaction requires the second requesting node to return a completion confirmation message; SENTC2CCOMP indicates whether the first interface agent has sent the completion response to the second chip; RCVDCHICOMP indicates whether the first interface agent has received the completion response returned by the first home node; and RCVDC2CCOMPACK indicates whether the first interface agent has received the actual completion confirmation message returned by the second chip. SNPCOMPACKHAZ indicates whether the corresponding subsequent consistency maintenance request is in a Snoop-CompAck hazard suspension state, and SNPCOMPACKHAZ_RHTENTRY records the index of the request processing entry that the subsequent consistency maintenance request is currently waiting for. Through the above field definitions, the aforementioned functional description can be further implemented at the level of specific status bits and associated fields, thereby facilitating the understanding of the internal coordination relationships between subsequent processes such as early confirmation, hazard identification, suspension establishment, and suspension release.

[0034] In some implementations, OWO type requests may also be involved. OWO stands for Ordered Write Observation Request, which is used to maintain the order in which multiple write transactions initiated by the same requesting node are observed. Because this type of request has stricter requirements on the source semantics and order semantics of completion confirmation, in some scenarios, it is not possible to simply return the completion confirmation in advance. Instead, it is necessary to wait for the peer to return the real completion confirmation message before completing the relevant processing on the local end.

[0035] refer to Figure 2 As shown, steps 101-105 of the transaction processing method in the chip interconnection scenario are described below with reference to specific embodiments: Step 101: Receive the target transaction sent through the second interface proxy, allocate a request processing entry for the target transaction, and forward the target transaction to the first home node.

[0036] Specifically, after the second requesting node in the second chip initiates the target transaction, the second interface proxy sends the target transaction to the first interface proxy in the first chip. Upon receiving the target transaction, the first interface proxy assigns a corresponding request processing entry to the target transaction, which records the attribute information and subsequent processing status of the target transaction, and forwards the target transaction to the first home node for processing. The request processing entry can serve as the basis for subsequent completion confirmation early return, hazard detection, and suspension release status.

[0037] As an optional embodiment, step 101, allocating a request processing entry for the target transaction, includes: recording the completion confirmation request status of the target transaction in the request processing entry; updating the completion response sending status of the request processing entry when sending the completion response to the second chip; updating the completion response receiving status of the request processing entry when receiving the completion response returned by the first home node; and updating the actual completion confirmation receiving status of the request processing entry when receiving the actual completion confirmation message returned by the second chip.

[0038] In the above embodiments, after receiving the target transaction forwarded by the second interface proxy, the first interface proxy not only forwards the request but also establishes a corresponding request processing entry for the target transaction to continuously track the processing of the target transaction on its own end.

[0039] The request processing entry can be understood as a status record unit established for each cross-chip receiving transaction, used to save the attributes and status information of the transaction at different processing stages, thereby providing a unified status basis for subsequent completion confirmation control, hazard judgment and request release.

[0040] In other words, the first interface agent not only undertakes the function of receiving and forwarding cross-chip transactions, but also undertakes the function of managing the protocol state related to the transaction. Therefore, the request processing entry is not only the basic structure of transaction tracking, but also facilitates the subsequent implementation of cross-chip completion confirmation optimization processing.

[0041] In some implementations, the request processing entry may record whether the target transaction requires completion confirmation, i.e., whether the transaction still needs a completion confirmation message from the peer requesting node after the completion response is returned. Correspondingly, it may also record whether the first interface proxy has sent a completion response to the second chip, whether it has received a completion response from the first home node, and whether it has received an actual completion confirmation message from the second chip. Through the above status records, the first interface proxy can clearly distinguish the current processing stage of the target transaction. For example, when the request processing entry indicates that the first home node has returned a completion response and the first interface proxy has sent the completion response to the second chip, but the actual completion confirmation message has not yet returned, it means that the transaction has met the conditions for early completion at its own end, but is still within the window period before the peer confirmation has returned. As another example, when the request processing entry indicates that the actual completion confirmation message has returned, it means that the transaction has entered the stage where the relevant suspension restrictions can be lifted and the final closing can be completed. Therefore, the status information in the request processing entry is not set in isolation, but rather collectively constitutes the basis for the judgment of subsequent processing logic.

[0042] Furthermore, compared to a processing method that merely forwards cross-chip requests without meticulously recording intermediate protocol states, this embodiment establishes and progressively updates request processing entries in step 101. This allows the first interface proxy to distinguish between different stages of the same transaction, such as having received a local completion response, having sent a completion response to the peer, not yet receiving actual completion confirmation from the peer, and having received actual completion confirmation from the peer. Each processing action no longer relies on coarse-grained transaction completion judgments but can be more precisely controlled based on fine-grained states. Because of this state distinction, the first interface proxy can return local completion confirmation to the first home node in advance when conditions are met, and simultaneously identify subsequent consistency maintenance requests that may cause order risks even before the peer's actual completion confirmation has been returned, and release the suspension at an appropriate time. In other words, the improvement in this embodiment is not merely adding a record entry, but rather pre-constructing a state foundation in the cross-chip consistency transaction processing chain that enables early confirmation and order risk control.

[0043] In this way, by establishing a request processing entry at the beginning of the transaction's local processing flow and continuously recording the completion confirmation request status, completion response sending status, completion response receiving status, and actual completion confirmation receiving status of the target transaction, this embodiment provides unified and reliable status support for subsequent early return of completion confirmation and consistency maintenance request control. This enables the first interface proxy to complete the local transaction earlier without disrupting the protocol order, reducing the continuous occupation of sorting and tracking resources by the first home node, improving transaction turnaround efficiency, and providing more precise control capabilities for the entire cross-chip consistency transaction processing flow.

[0044] Step 102: After receiving the completion response returned by the first home node and having already sent the completion response to the second chip, if no actual completion confirmation message is received from the second chip, a first completion confirmation message is sent to the first home node.

[0045] Specifically, after the first home node completes processing the target transaction, it can return a completion response, such as Comp or CompData, to the first interface proxy. Upon receiving this completion response and having already forwarded it to the second chip, the first interface proxy can send a first completion confirmation message to the first home node without waiting for the second requesting node in the second chip to actually return a completion confirmation message. This decouples the local transaction completion from the cross-chip completion confirmation round trip, allowing the first home node to complete the corresponding transaction's final processing ahead of time and release related resources.

[0046] The completion response can be either Comp or CompData, indicating that the first home node has completed processing the target transaction at the home node. The actual completion confirmation message can be a CompAck sent back by the peer requesting node after receiving the completion response, indicating that the peer requesting node has received the corresponding completion response.

[0047] In standard cross-chip transaction processing, the first home node typically needs to wait for the actual completion confirmation message to be returned via the second chip before it can complete the closing processing of its local transaction and release the corresponding resources. In contrast, this application's embodiment introduces a local early confirmation mechanism on the first interface proxy side. That is, after the local end has received the completion response and sent it to the peer, the first interface proxy returns a first completion confirmation message to the first home node, eliminating the requirement that the completion time of the local transaction must serially depend on the cross-chip completion confirmation round trip.

[0048] In addition to sending confirmation messages in advance, this application embodiment also employs a processing mechanism based on a reclassification of the role of the completion confirmation protocol. Specifically, the completion confirmation message plays at least two roles in cross-chip consistency transactions: first, as a closing signal indicating the completion of the local transaction, it enables the first home node to end the current transaction and release related tracking, sorting, or buffering resources; second, as the order basis for subsequent consistency maintenance operations, it indicates that the peer requesting node has stably observed the transaction result. Regarding the former role, this embodiment considers that as long as the first interface proxy has received the completion response returned by the first home node and has sent the completion response to the second chip, the confirmation conditions required for transaction completion can be completed semantically at the local end. Therefore, the first completion confirmation message can be sent to the first home node first. As a result, the completion of the transaction of the first home node no longer needs to wait for the peer's real confirmation message to return via the link, and local resources can be released earlier, thereby improving completion latency and resource turnover efficiency.

[0049] This embodiment does not neglect the role of completion confirmation messages in maintaining order. Instead, it continues to track actual completion confirmation messages in subsequent steps and controls the timing of subsequent consistency maintenance requests based on these messages. In other words, this embodiment decouples the requirements for local transaction completion and cross-chip order assurance. Specifically, for local transaction completion, the first interface proxy is allowed to return the first completion confirmation message to the first home node first. For subsequent consistency maintenance requests that may affect the consistency order, the actual completion confirmation message returned by the second chip is still used as the basis for subsequent control. This approach reduces the sensitivity of local transaction completion time to cross-chip link latency without compromising protocol correctness.

[0050] As an optional embodiment, in step 102, sending a first completion confirmation message to the first home node when no actual completion confirmation message is received from the second chip includes: determining whether the target transaction is a transaction carrying a completion confirmation expectation attribute; if the target transaction is a transaction carrying a completion confirmation expectation attribute, and the first interface proxy has received a completion response returned by the first home node and has sent the completion response to the second chip, then sending the first completion confirmation message to the first home node.

[0051] In the above embodiments, the transaction carrying the completion confirmation expectation attribute can be understood as a transaction request with a completion confirmation expectation identifier, that is, such a transaction semantically requires the requesting node to send back a completion confirmation message after receiving the completion response. Accordingly, the first interface proxy can record whether the target transaction has a completion confirmation requirement in the request processing entry established for the target transaction, and determine whether the target transaction meets the condition of returning the first completion confirmation message in combination with the completion response reception status and completion response outward transmission status of the first home node. In this embodiment, by jointly judging the transaction attribute and the current processing stage, early confirmation is selectively performed on transactions that meet the conditions, thereby ensuring that the early confirmation action has clear protocol boundaries and state basis.

[0052] Furthermore, in the implementation using field-level state records, the first interface proxy can allow the corresponding target transaction to participate in the arbitration of sending the first completion confirmation message on the local side when EXPCOMPACK, RCVDCHICOMP, and SENTC2CCOMP are all valid, without having to use RCVDC2CCOMPACK as a precondition for early confirmation on the local side. In other words, as long as the target transaction itself requests a completion confirmation message, and the first interface proxy has received the completion response from the first home node and sent that response to the second chip, it can semantically complete the confirmation conditions required for transaction closure on the local side. This decouples the local transaction completion path from cross-chip round trips and also preserves an independent sequential constraint path for controlling the release of consistency maintenance requests through actual completion confirmation messages. This allows the two types of processing logic—early completion on the local side and release of subsequent requests only after the peer has truly completed its task—to be coordinated and implemented within the same state system.

[0053] Further optionally, after determining whether the target transaction is a transaction carrying a completion confirmation expectation attribute, the method further includes: determining whether the target transaction is an ordered write observation request; if the target transaction is determined to be an ordered write observation request, prohibiting the first interface proxy from sending the first completion confirmation message to the first home node before receiving the actual completion confirmation message; and sending a completion confirmation message to the first home node after receiving the actual completion confirmation message returned by the second chip.

[0054] In the above optional embodiments, ordered write observation requests correspond to transaction types with stricter constraints on the order of write transaction observations. For these types of transactions, the completion confirmation message not only indicates that the completion response has been received, but also carries stronger sequential semantic requirements. Therefore, it is not appropriate to directly adopt the local end's method of pre-completing the confirmation. Based on this, this embodiment excludes this type of transaction from the early return path, allowing it to still wait for the second chip to return the real completion confirmation message according to a more stringent processing method before sending the completion confirmation message to the first home node. By distinguishing between transactions that generally carry the expectation of completion confirmation and ordered write observation requests, this embodiment can expand the scope of application of early confirmation as much as possible, improve the efficiency of local resource release, and also take into account the strict requirements of special transaction types on sequential semantics and observation semantics, thereby ensuring the correctness and applicability of the entire cross-chip consistency transaction processing process.

[0055] The related transaction can be understood as a preceding target transaction that has already received a completion response on its local end, and the first interface proxy has sent the corresponding completion response to the second chip. It has also sent a first completion confirmation message to the first home node in advance, but the actual completion confirmation message corresponding to this target transaction has not yet been returned from the second requesting node to the first interface proxy via the second interface proxy. This related transaction exists within a window period where it has been pre-confirmed on its local end but not yet truly confirmed on the peer end. For subsequent consistency maintenance requests, only when there is a preceding transaction of this type that targets the same source node and accesses the same cache line will an order risk requiring additional control arise.

[0056] Step 104: When the associated transaction is identified, the subsequent consistency maintenance request is suspended, and the request processing entry index corresponding to the associated transaction is recorded, so as to prevent the subsequent consistency maintenance request from being sent to the second chip during the suspension period.

[0057] Specifically, after the first interface proxy sends a first completion confirmation message to the first home node in advance, the first home node may initiate subsequent consistency maintenance requests, such as eavesdropping requests, against the same target node and the same cache line based on the first completion confirmation message. At this time, the first interface proxy can match the aforementioned request processing entries based on the address information and target source node identifier of the subsequent consistency maintenance request to determine whether there are any related transactions that have been confirmed in advance but have not yet received the actual completion confirmation message from the peer. If such related transactions exist, it indicates that the subsequent consistency maintenance request falls into a risk window. To prevent the subsequent consistency maintenance request from reaching the second requesting node prematurely, the first interface proxy can suspend it and record the corresponding request processing entry index, so that the subsequent consistency maintenance request does not participate in the transmission to the second chip.

[0058] For example, in one instance, the same second requesting node initiates two read transactions for the same cache line, the first of which is denoted as Transaction 1. After receiving the completion response from the first home node for Transaction 1 and forwarding it to the second chip, the first interface proxy first returns a first completion confirmation message to the first home node. At this point, the request processing entry for Transaction 1 can be represented as follows: completion confirmation request status is valid, completion response sending status is valid, and completion response receiving status is valid, while the actual completion confirmation receiving status is invalid. If, during this period, the first home node initiates a listener request for the same second requesting node and the same cache line based on the first completion confirmation message it has already received, then this listener request is associated with Transaction 1. If the listener request is issued directly without control, it may arrive at the second requesting node before the actual completion confirmation message for Transaction 1, thereby disrupting the consistent transaction order.

[0059] Therefore, instead of uniformly blocking all subsequent consistency maintenance requests, this embodiment performs targeted suspension control on subsequent consistency maintenance requests that hit the above-mentioned risk window and satisfy the dual association relationship of node and address with the preceding target transaction, thereby ensuring the correctness of the protocol while preserving the normal concurrent processing capability of other transactions as much as possible.

[0060] As an optional embodiment, in step 103, the request processing entries are matched based on the address information and target source node identifier of the subsequent consistency maintenance request to identify whether there are any associated transactions that have sent the first completion confirmation message but have not yet received the actual completion confirmation message. This includes: if the subsequent consistency maintenance request is a listening request initiated against the second request node, obtaining the address information and target source node identifier of the listening request; and comparing the address information and target source node identifier with the address information and source node identifier recorded in each of the request processing entries. Specifically, the associated transaction is identified when a request processing entry meets the following conditions: the address information recorded in the request processing entry matches the address information of the listening request; the source node identifier recorded in the request processing entry matches the target source node identifier of the listening request; the target transaction corresponding to the request processing entry has sent a completion response to the second chip; the target transaction corresponding to the request processing entry needs to return a completion confirmation message; and the target transaction corresponding to the request processing entry has not yet received the actual completion confirmation message returned by the second chip.

[0061] The aforementioned identification process essentially defines the boundary for determining whether subsequent consistency maintenance requests will hit a risk window. That is, the existence of the associated transaction is only confirmed when the node identifier matches, the cache line address matches, the target transaction has entered the completion response outbound stage, the target transaction itself requests a completion confirmation, and the corresponding actual completion confirmation has not yet returned to the local end. This multi-condition joint determination avoids misjudging transactions unrelated to the current subsequent consistency maintenance request as sources of risk, thereby improving the accuracy of suspension control.

[0062] Specifically, the above determination process can be understood as follows: first, by matching address information, the comparison range is limited to the transaction set corresponding to the same cache line; then, by matching source node identifiers, the comparison range is further limited to transactions initiated by the same requesting node, thereby ensuring that the identified target transaction and the current listening request have the same requesting node and the same cache line. Subsequently, the state conditions are combined for filtering: if a certain request processing entry indicates that the corresponding target transaction has sent a completion response to the second chip, it means that the target transaction has progressed to the completion response return stage on the local processing path; if the target transaction also belongs to the transaction that needs to return a completion confirmation message, it means that the transaction still has a subsequent stage in terms of protocol semantics that is waiting for the completion confirmation from the second chip; and when the request processing entry further indicates that the actual completion confirmation message returned by the second chip has not yet been received, it means that the target transaction is in a risk window where "the local end can consider it to be completed based on the early return mechanism, but the actual completion of the second chip has not yet been confirmed by the local end."

[0063] Therefore, when the address matching, source node identifier matching, and state conditions are all met simultaneously, it can be determined that the current listening request has hit a preceding target transaction with which it has an order association, and this preceding target transaction is identified as the associated transaction. In other words, any unfinished transaction cannot be identified as an associated transaction. An associated transaction can be understood as: a target transaction that has a consistency order constraint with the current listening request regarding the same request node and the same cache line, and has already sent a completion response to the second chip, needs to return a completion confirmation message, but the actual completion confirmation message has not yet been returned.

[0064] In one example, a peer requesting node initiates a target transaction for a specific cache line. This target transaction is sent to the first interface proxy via the second interface proxy and then forwarded by the first interface proxy to the first home node. After the first home node returns a completion response, the first interface proxy sends the completion response to the second chip side but has not yet received the actual completion confirmation message returned by the second chip side. At this time, if the first home node then initiates a probe request for the same cache line to the same requesting node, the first interface proxy can use the address information and target source node identifier of the probe request to compare the request processing entries. If a request processing entry happens to record the same cache line address and the same source node identifier, and the transaction corresponding to this entry meets the conditions of having issued a completion response, needing to return a completion confirmation message, and not yet receiving an actual completion confirmation message, it indicates that if the current probe request is sent immediately, it may arrive earlier than the actual completion time of the target transaction on the second chip side, thus causing a consistency order risk. Therefore, this target transaction is identified as the associated transaction.

[0065] Optionally, the first interface agent can perform the comparison operation in parallel on multiple request processing entries to improve the efficiency of related transaction identification. Furthermore, the condition "the actual completion confirmation message returned by the second chip has not yet been received" can be further limited to the condition that the corresponding status bit is not set and has not been synchronously set within the current detection cycle, thereby avoiding misjudgment when the listening request and the actual completion confirmation message arrive in adjacent cycles. Through the above determination process, the first interface agent can accurately identify the related transactions that will truly trigger the Snoop-CompAck hazard from all in-transit transactions, providing a basis for subsequent suspension control and unsustainment processing.

[0066] In some implementations, the matching of the request processing entries can be performed using a parallel content addressing comparison method. This allows for rapid determination of whether an associated transaction is matched when subsequent consistency maintenance requests enter the processing pipeline, thereby reducing the additional latency introduced by hazard detection itself. Furthermore, the condition that the target transaction corresponding to the request processing entry has not yet received the actual completion confirmation message returned by the second chip can be defined as follows: the corresponding status bit is invalid, and it has not been synchronously set within the current processing cycle. By introducing this timing constraint, misjudgments can be further avoided when the actual completion confirmation message arrives at the boundary period.

[0067] As an optional embodiment, after matching the request processing entries based on the address information and target source node identifier of the subsequent consistency maintenance request in step 103, the method further includes: determining whether the same subsequent consistency maintenance request matches multiple request processing entries simultaneously; if the determination result is yes, blocking the establishment or sending of the suspended association of the subsequent consistency maintenance request; and when only a unique associated transaction remains among the multiple request processing entries, establishing the association between the subsequent consistency maintenance request and the request processing entry corresponding to the unique associated transaction.

[0068] The above implementation corresponds to a multiple hazard scenario. A multiple hazard refers to a situation where the same subsequent consistency maintenance request simultaneously hits multiple request processing entries that are still within the window that have been pre-confirmed on the local end but not yet truly confirmed on the remote end.

[0069] In one example, when the same second requesting node initiates Transaction 1 and Transaction 2 consecutively for the same cached line within a short period, and the actual completion confirmation message for Transaction 1 is significantly delayed due to link congestion, while Transaction 2 has completed its local processing and enabled the first home node to initiate a subsequent listener request, the current listener request may simultaneously form candidate associations with both Transaction 1 and Transaction 2. If either association is directly established in this situation, the listener request may be incorrectly released when the earlier returned actual completion confirmation message arrives, resulting in an order violation. Therefore, this embodiment does not immediately establish a suspended association when multiple hazards are detected. Instead, it first blocks the subsequent consistency maintenance request until only one valid item remains among the multiple candidate association transactions, and then establishes a unique binding relationship. This can further improve the robustness of the system under complex link timing conditions.

[0070] Furthermore, the aforementioned multiple hazard scenarios can be triggered by the following conditions: First, the same second requesting node initiates multiple transactions consecutively for the same cache line within a short period. After the completion response of the previous transaction reaches the second requesting node, the second requesting node immediately returns the actual completion confirmation message of the previous transaction and continues to initiate the next new transaction. Second, after receiving the first completion confirmation message returned early by the first interface proxy for the next transaction, the first home node immediately initiates a subsequent consistency maintenance request for the same second requesting node and the same cache line. Third, the actual completion confirmation message corresponding to the previous transaction experiences a severe delay on the cross-chip return path, causing its propagation delay to be greater than the total processing delay on the chain of "completion response reaching the second requesting node, the second requesting node initiating the next transaction, the next transaction reaching the first interface proxy via the second interface proxy, and the first home node completing the next transaction and triggering the subsequent consistency maintenance request." In this case, although the later-initiated transaction is later than the previous transaction in time sequence, the subsequent consistency maintenance request it triggers may enter the hazard detection path earlier, thus forming multiple candidate associations with the previous transaction that has not yet been truly completed.

[0071] Since multiple timing conditions must be met simultaneously, multiple hazards are typically low-probability events. Therefore, this application's embodiment employs a method of blocking when multiple hazards are detected, and then establishing a suspended association only after convergence to a single associated transaction. This eliminates the need for an additional independent, large-capacity buffer structure or a more complex multi-binding-release structure for multiple hazards, further reducing hardware resource consumption and implementation complexity. This approach avoids prematurely establishing a single binding relationship between an SHT entry and a candidate request processing entry, leading to erroneous releases, while ensuring consistent ordering under complex link conditions with relatively low hardware overhead. This demonstrates the advantages of trade-offs in implementation for low-probability abnormal timing scenarios.

[0072] As an optional embodiment, step 104 involves suspending the subsequent consistency maintenance request and recording the request processing entry index corresponding to the associated transaction, including: allocating a consistency maintenance processing entry to the subsequent consistency maintenance request; writing the subsequent consistency maintenance request into the consistency maintenance processing entry; setting an hazard flag in the consistency maintenance processing entry; writing the request processing entry index corresponding to the associated transaction into the association field of the consistency maintenance processing entry; and removing the consistency maintenance processing entry from the arbitration process based on the hazard flag, so that the subsequent consistency maintenance request enters a suspended state.

[0073] In some implementations, the subsequent consistency maintenance request may be a Snoop request initiated by the first home node for the same second requesting node and the same cache line. When the first interface proxy identifies that the subsequent consistency maintenance request hits a related transaction that has been pre-confirmed on the local side but has not yet been confirmed by the second chip side, the above-mentioned suspension establishment process can be completed when the subsequent consistency maintenance request enters the local processing path, thereby preventing the subsequent consistency maintenance request from being sent to the second chip prematurely before the sequence conditions are met.

[0074] The consistency maintenance processing entry can be used to store the temporary state of subsequent consistency maintenance requests on the local end and their binding relationship with related transactions. By setting the hazard flag, subsequent consistency maintenance requests that hit the risk window can be distinguished from ordinary subsequent consistency maintenance requests that can be sent directly. By recording the request processing entry index corresponding to the related transaction, it is possible to quickly locate and unsuspend the request when the corresponding actual completion confirmation message is received. In other words, the first interface proxy can first save the request in the consistency maintenance processing entry instead of directly discarding or requiring it to be re-initiated. This ensures that although the subsequent consistency maintenance request is not sent out temporarily, its control information, target information, and correspondence with related transactions are still preserved. Therefore, when the actual completion confirmation message corresponding to the related transaction is received, the first interface proxy can quickly perform a reverse lookup and release based on the recorded request processing entry index, without having to perform complex judgments on all suspended requests one by one.

[0075] Compared to adding a separate cache queue or adopting a global pause mechanism, the above solution achieves targeted suspension control of requests hitting hazard levels by adding an hazard flag and an associated field to the consistency maintenance processing entries. This not only reduces implementation overhead but also helps limit the suspension granularity to requests hitting the risk window, thus balancing protocol correctness and hardware resource efficiency. This solution can reuse existing consistency maintenance processing structures; simply adding fields to identify the hazard state and record the associated transaction index enables the connection between suspension establishment and subsequent suspension release. Therefore, there is no need to configure separate large-capacity cache resources or more complex global control logic for this type of hazard control. Furthermore, after receiving the actual completion confirmation message from the second chip, the associated field can be used to target and release specific suspended requests, thus limiting the suspension control scope to requests that truly hit the risk window and reducing the impact on the processing capacity of other normal concurrent requests.

[0076] Step 105: Upon receiving the actual completion confirmation message returned by the second chip, update the corresponding request processing entry according to the transaction identifier, and release the suspended state of the corresponding subsequent consistency maintenance request according to the updated request processing entry index, so that the subsequent consistency maintenance request can be re-entered for transmission.

[0077] It should be noted that in the aforementioned steps, the first interface proxy has already identified the associated transaction corresponding to the subsequent consistency maintenance request based on the address information, target source node identifier, and transaction status, and has temporarily suspended the subsequent consistency maintenance request through the consistency maintenance processing entry. Therefore, in this step, the actual completion confirmation message returned by the second chip is no longer a prerequisite for the completion of the local transaction, but rather serves as the trigger for releasing the suspended state. In other words, this embodiment separates the early establishment of the local completion semantics from the actual release of the subsequent consistency maintenance request: the former is used to shorten the local transaction closure path, and the latter is used to restore cross-chip consistency order constraints, thereby improving the local resource turnover efficiency while ensuring protocol correctness.

[0078] Specifically, after receiving the completion response, the second requesting node can return an actual completion confirmation message to the first interface proxy via the second interface proxy. Upon receiving this confirmation message, the first interface proxy can locate the corresponding request processing entry based on the transaction identifier carried within it and update the completion confirmation reception status of that request processing entry. Subsequently, the first interface proxy can find the associated suspended subsequent consistency maintenance request based on the updated request processing entry index, release its suspension status, and re-enter arbitration to send it to the second chip. This ensures that the subsequent consistency maintenance request arrives at the second chip only after the corresponding transaction of the second requesting node has truly completed, thereby maintaining the cross-chip consistency transaction processing order.

[0079] In one example, the second requesting node initiates transaction 1 for a certain cache line. Transaction 1 is sent to the first interface proxy via the second interface proxy and then forwarded by the first interface proxy to the first home node for processing. After the first home node returns a completion response, the first interface proxy has already sent the completion response to the second chip side and can provide feedback on the completion confirmation semantics to the first home node based on the aforementioned early return mechanism. Subsequently, if the first home node initiates a subsequent consistency maintenance request for the same cache line and to the same second requesting node, this subsequent consistency maintenance request has been identified as hitting the risk window corresponding to transaction 1 in the aforementioned steps and is written into the consistency maintenance processing entry and suspended for storage. When the second requesting node actually receives the completion response of transaction 1 and sends back the actual completion confirmation message corresponding to transaction 1 via the second interface proxy, the first interface proxy can use the transaction identifier in the message to locate the request processing entry corresponding to transaction 1, and after updating the completion confirmation reception status of the request processing entry, use the index of the request processing entry to match the associated fields of the consistency maintenance processing entry. If the associated field recorded in a consistency maintenance entry matches the index of the request processing entry, it indicates that the pending subsequent consistency maintenance request in that entry is indeed a request waiting for transaction 1 to complete. Therefore, the hazard flag of that consistency maintenance entry can be cleared, allowing the subsequent consistency maintenance request to regain its eligibility to send and rejoin the arbitration process. In this way, it can be ensured that the subsequent consistency maintenance request arrives later than the actual completion time of transaction 1 on the second requesting node side, avoiding order violations caused by prematurely returning to the local end for confirmation.

[0080] Furthermore, the transaction identifier location in this step can directly utilize the transaction correspondence naturally carried in the actual completion confirmation message to accurately hit the request processing entry, without needing to perform an address-level search on all in-transit transactions again. Therefore, the release path is more direct than the detection path. Meanwhile, since the aforementioned steps have already recorded the request processing entry index corresponding to the associated transaction in the consistency maintenance processing entry, this step, after completing the request processing entry status update, can quickly look up the corresponding suspended subsequent consistency maintenance requests based on this entry index, achieving "targeted release driven by the actual completion confirmation message." Compared to using broadcast traversal release or global pause and recovery methods, the above processing not only reduces control complexity but also helps to precisely limit the release action to the scope of requests truly affected by the actual completion confirmation message, thereby further reducing hardware implementation overhead.

[0081] Furthermore, in scenarios with multiple transactions in transit, the release logic in this step maintains a clear causal relationship: the subsequent consistency maintenance request bound to the transaction that returns its actual completion confirmation message first is released first; while for other related transactions that have not yet received their actual completion confirmation message, their corresponding suspended subsequent consistency maintenance requests remain suspended. This avoids prematurely releasing subsequent consistency maintenance requests that do not meet the order conditions, and also avoids unnecessary waiting for requests that already meet the release conditions, thus balancing sequential correctness and processing efficiency.

[0082] As an optional embodiment, step 105, which involves updating the corresponding request processing entry based on the transaction identifier and releasing the pending state of the corresponding subsequent consistency maintenance request based on the updated request processing entry index, includes: Based on the transaction identifier carried in the actual completion confirmation message, locate the request processing entry corresponding to the actual completion confirmation message; update the actual completion confirmation reception status of the request processing entry; match the associated fields of each consistency maintenance processing entry with the updated request processing entry index; when the associated field of a consistency maintenance processing entry matches the updated request processing entry index, clear the hazard flag of that consistency maintenance processing entry; after the hazard flag is cleared, allow the corresponding subsequent consistency maintenance request to re-enter arbitration.

[0083] In the above optional embodiments, the request processing entry can be used to record the processing progress of the cross-chip target transaction on the local end, including at least status information such as whether a completion response has been sent to the second chip, whether a completion confirmation message needs to be returned, and whether an actual completion confirmation message has been received from the second chip; the consistency maintenance processing entry can be used to record the temporary storage status of subsequent consistency maintenance requests on the local end, as well as the binding relationship between the subsequent consistency maintenance request and its associated transaction. Based on the coordinated cooperation of the above two types of entries, the first interface proxy can update the target transaction status after receiving the actual completion confirmation message, and then use the entry index as a bridge to transmit the status change to the corresponding suspended subsequent consistency maintenance request, thereby forming an ordered release path from actual completion to resumption of transmission.

[0084] In some implementations, after receiving the actual completion confirmation message, the first interface proxy can first use the transaction identifier carried in the message to directly match the corresponding request processing entry. Only when the request processing entry indicates that the target transaction needs to return a completion confirmation message, and its actual completion confirmation reception status was previously "not received," is the actual completion confirmation reception status of the request processing entry updated. Subsequently, the update of the actual completion confirmation reception status can further trigger matching of the associated fields of each consistency maintenance processing entry using the request processing entry index as the search key. For consistency maintenance processing entries where the hazard flag is valid and the associated field matches the request processing entry index, its hazard flag is cleared and the suspension is lifted. By adding the above state boundary judgment, on the one hand, it can avoid interference from repeated or invalid completion confirmation messages on the suspension release process; on the other hand, it can also establish a one-to-one correspondence between the release action and the aforementioned hazard establishment process at the field level state, thereby further improving the determinism of release control.

[0085] In a specific example, if the index of the request processing entry corresponding to transaction 1 is E1, and the value recorded in the associated field of the consistency maintenance processing entry corresponding to a subsequent consistency maintenance request is also E1, then after the first interface agent receives the actual completion confirmation message corresponding to transaction 1, it only needs to locate and update the request processing entry with index E1 based on the actual completion confirmation message to further locate the consistency maintenance processing entry and clear its hazard flag. Therefore, without the need to establish an additional independent release queue or perform complex judgments on all pending consistency maintenance processing entries, the pending state can be quickly released. This design allows the actual completion confirmation message to both confirm the actual completion of the target transaction and trigger the resumption of sending of the corresponding subsequent consistency maintenance request, thereby enhancing the determinism and simplicity of the release process.

[0086] Compared to methods that simply rely on time delays, global recovery, or additional caching structures, the above scheme achieves precise release of pending subsequent consistency maintenance requests through a two-level association mechanism: locating request processing entries using transaction identifiers and reverse-looking up consistency maintenance processing entries using request processing entry indexes. This approach not only avoids unnecessary waiting caused by overly coarse-grained releases but also reduces the overhead of additional control logic and storage resources while maintaining protocol order.

[0087] See Figure 3 Figure 3 illustrates a schematic flow in this embodiment of the application where the first interface proxy returns the first completion confirmation message in advance on the CHIP2CHIP receiving side. Taking a ReadUnique transaction initiated by the second requesting node on the peer end as an example... Figure 3In the context of ReadUnique, it represents a target read transaction initiated by the second requesting node on the peer end, forwarded by the second interface proxy to the first interface proxy, and then forwarded by the first interface proxy to the first home node for processing. Figure 3 The CompData in the table represents the completion response and related data returned by the first home node after completing the ReadUnique transaction. Figure 3 In this context, CompAck represents the completion confirmation message corresponding to the ReadUnique transaction. Specifically, after the ReadUnique transaction is sent to the first interface proxy via the second interface proxy, it is forwarded by the first interface proxy to the first home node for processing. After the first home node completes processing and returns CompData, the first interface proxy sends the CompData to the second interface proxy, which then forwards it to the second requesting node. Furthermore, if the local end has received the CompData and has already sent the CompData to the second chip, the first interface proxy sends a first completion confirmation message to the first home node without waiting for the actual completion confirmation message CompAck returned by the second requesting node to reach the first interface proxy via the second interface proxy before forwarding it to the first home node. Through this processing method, the first home node can complete the closing processing of its own transaction in advance based on the first completion confirmation message and release the corresponding sorting and tracking resources, thereby decoupling the local transaction completion path from the cross-chip completion confirmation round-trip path. After the second requesting node actually receives the CompData, it can still return the actual completion confirmation message CompAck according to the protocol for the first interface proxy to continue using in the subsequent sequence control process.

[0088] In the introduction Figure 3 Following the early return mechanism shown, the subsequent consistency maintenance order issue needs to be addressed. See also... Figure 4 , Figure 4 This illustrates the Snoop-CompAck adventure scenario that might occur if the user prematurely returns to the first completion confirmation message. Figure 4 In the diagram, ReadUnique represents the target read transaction initiated by the second requesting node and forwarded by the second interface proxy and the first interface proxy to the first home node for processing. CompData represents the completion response and related data returned by the first home node for the ReadUnique transaction. CompAck represents the actual completion confirmation message corresponding to the target transaction. Snoop represents the consistency maintenance request subsequently initiated by the first home node for the same second requesting node and the same cache line. The snp-compack hazard in the diagram represents the sequence hazard window formed between the Snoop request and the actual completion confirmation message that has not yet returned to the local end.

[0089] Taking the ReadUnique transaction as an example, after the first interface agent sends the first completion confirmation message to the first home node in advance, the first home node may assume that the second requesting node has completed receiving and observing the result of the transaction based on this message, and then initiate a subsequent consistency maintenance request, such as a Snoop request, for the same second requesting node and the same cache line. However, at this time, the actual completion confirmation message CompAck corresponding to the second requesting node may still be on its way from the second requesting node back to the first interface agent through the second interface agent, and has not yet been actually received by the first interface agent. If this subsequent consistency maintenance request is not controlled, but is directly sent by the first interface agent to the second chip, then this subsequent consistency maintenance request may arrive at the second requesting node before the actual completion confirmation message CompAck, thus causing the second requesting node to receive the subsequent consistency maintenance request for the same cache line before completing the confirmation of the preceding transaction, thereby violating the order relationship required by the CHI protocol. This order problem essentially corresponds to the situation where the local end has returned a completion confirmation in advance, but the peer end's actual completion confirmation has not yet returned to the local end, and the subsequent Snoop request on the same second requesting node and the same cache line is prematurely allowed. Based on this, the embodiments of this application do not simply prohibit the early return of the first completion confirmation message, but further implement interception and suspension control only for subsequent consistency maintenance requests that are within the window period where the local end has already confirmed, the peer end has not yet confirmed, and they are directed to the same second request node and the same cache line. The suspension is lifted and the subsequent consistency maintenance request is allowed to continue being sent only after the first interface proxy subsequently receives the corresponding actual completion confirmation message. Thus, Figure 4 The process shown reflects the way in which the second type of function of the completion confirmation message is retained in the embodiments of this application. That is, the actual completion confirmation message of the peer is still used as the basis for releasing the subsequent consistency maintenance request, so as to maintain the correctness of the cross-chip consistency transaction processing order while obtaining the benefit of early completion.

[0090] See Figure 5 , Figure 5 The illustration shows a schematic flow of multiple Snoop-CompAck adventure scenarios in an embodiment of this application. Figure 5In this context, ReadUnique(#1) and ReadUnique(#2) represent the first and second target read transactions initiated consecutively by the same second requesting node for the same cache line within a short period of time. CompData(#1) and CompData(#2) represent the completion responses and related data returned by the first home node for the above two target read transactions. CompAck(#1) and CompAck(#2) represent the actual completion confirmation messages corresponding to the above two target read transactions. Snoop represents the consistency maintenance requests subsequently initiated by the first home node for the same second requesting node and the same cache line. Figure 5 The term "multi hazard" indicates that when the Snoop request enters the local processing path, it simultaneously hits multiple request processing entries that have been pre-confirmed by the local end but not actually confirmed by the other end, thus forming multiple hazards.

[0091] Specifically, in Figure 5 In the example shown, the second requesting node first initiates ReadUnique(#1), which is sent to the first interface proxy via the second interface proxy and then forwarded to the first home node for processing. After the first home node returns CompData(#1), the first interface proxy can send the first completion confirmation message corresponding to the transaction to the first home node, while CompAck(#1) is still transmitted along the path from the second requesting node and the second interface proxy back to the first interface proxy. Subsequently, the second requesting node continues to initiate ReadUnique(#2), which is also forwarded to the first home node for processing via the second and first interface proxies. After the first home node returns CompData(#2), the first interface proxy can also send the corresponding first completion confirmation message to the first home node in advance for ReadUnique(#2). Because CompAck(#1) experiences a significant delay in the cross-chip return path, while the processing flow corresponding to ReadUnique(#2) proceeds more quickly, when the first home node subsequently initiates a Snoop request for the same second request node and the same cache line, this Snoop request may fall into the risk windows corresponding to both ReadUnique(#1) and ReadUnique(#2), thus creating a risk on the local HA side. Figure 5 The multi hazard is shown.

[0092] Multiple hazard scenarios typically require multiple timing conditions to occur simultaneously. Specifically, the confirmation message for the completion of a previous transaction may be significantly delayed due to congestion or priority suppression on the link, while a subsequent transaction has already completed its local processing and prompted the first home node to initiate a subsequent consistency maintenance request. In this situation, if the first interface proxy, upon detecting that the current Snoop request hits multiple request processing entries, still directly selects one of them to establish a single binding relationship, then when the earlier confirmation message arrives, it may incorrectly release the Snoop request from its pending state. This could lead to the Snoop request being prematurely released before another preceding transaction has actually completed, violating the ordering requirements of the CHI protocol.

[0093] Based on this, the embodiments of this application detect... Figure 5 In the case of multi-hazard scenarios, the final consistency maintenance entry binding relationship is not immediately assigned to the Snoop request. Instead, the establishment or sending of the suspended association for the Snoop request is preferably blocked first. Only after multiple candidate association transactions converge to a single valid entry is the association relationship between the Snoop request and the unique request processing entry established, and the corresponding request processing entry index is recorded. This approach avoids the problem of accidental release caused by prematurely establishing incorrect binding relationships in multi-hazard scenarios. Furthermore, it ensures the correctness of the consistency transaction processing order under complex link timing conditions with low hardware overhead, without requiring additional complex multi-binding release structures.

[0094] In this embodiment, by establishing a request processing entry for the target transaction on the first chip side, and after receiving the completion response returned by the first home node and having already sent the completion response to the second chip, a first completion confirmation message is sent to the first home node. At the same time, for subsequent consistency maintenance requests, associated transaction identification based on address information and target source node identifier, suspension control, and release processing after receiving the actual completion confirmation message are performed. This allows for the early completion of the local transaction without waiting for a complete round trip of cross-chip completion confirmation, resulting in earlier release of local resources and the sequential issuance of subsequent consistency maintenance requests. This reduces the time occupied by transaction tracking and sorting resources of the first home node, improves transaction turnaround efficiency and system throughput, and reduces the risk of consistency order violations caused by simply returning completion confirmation early.

[0095] The above describes a transaction processing method in an inter-chip interconnection scenario according to an embodiment of this application. The following describes a transaction processing system in an inter-chip interconnection scenario that executes the above method.

[0096] See Figure 6 , Figure 6This is a schematic diagram of a transaction processing system in an inter-chip interconnection scenario provided by an embodiment of this application. The system includes a first chip 601 and a second chip 602; in some embodiments, the transaction processing system further includes a first home node in the first chip 601 and a second interface proxy and a second request node in the second chip 602. The second interface proxy is used to send the target transaction initiated by the second request node to the first interface proxy and forward the completion response returned by the first interface proxy to the second request node; the first home node is used to process the target transaction and return a completion response, and to issue subsequent consistency maintenance requests during subsequent processing; the second request node is used to return an actual completion confirmation message to the first interface proxy after receiving the completion response.

[0097] Specifically, in the above system, the second interface proxy of the second chip 602 is configured to send the target transaction initiated by the second requesting node to the first interface proxy, and forward the completion response returned by the first interface proxy to the second requesting node; The first interface agent of the first chip 601 is configured to receive the target transaction sent through the second interface agent, allocate a request processing entry for the target transaction, and forward the target transaction to the first home node; after receiving the completion response returned by the first home node and having sent a completion response to the second interface agent, and without receiving the actual completion confirmation message returned by the second chip 602, it sends a first completion confirmation message to the first home node. The first home node of the first chip 601 is configured to process the target transaction and return a completion response, as well as issue subsequent consistency maintenance requests during subsequent processing. The second request node of the second chip 602 is configured to return an actual completion confirmation message to the first interface proxy after receiving the completion response; The first interface proxy is also configured to, upon receiving a subsequent consistency maintenance request from the first home node, match the request processing entries based on the address information and target source node identifier of the subsequent consistency maintenance request to identify whether there are any associated transactions that have sent a first completion confirmation message but have not yet received an actual completion confirmation message; when an associated transaction is identified, the subsequent consistency maintenance request is written into the consistency maintenance processing tracker and set to suspension, and the index of the request processing entry corresponding to the associated transaction is recorded; when an actual completion confirmation message is received, the corresponding request processing entry is updated according to the transaction identifier, and the suspension state of the corresponding subsequent consistency maintenance request is released according to the updated request processing entry index, so that the subsequent consistency maintenance request can be re-entered for transmission.

[0098] In this embodiment, by allocating request processing entries for the target transaction on the first chip side, and after receiving the completion response returned by the first home node and having sent a completion response to the second interface proxy, a first completion confirmation message is sent to the first home node without receiving the actual completion confirmation message returned by the second chip; then, upon receiving a subsequent consistency maintenance request, the associated transaction is identified, and suspension control is performed on the subsequent consistency maintenance request that hits the risk window; and after receiving the actual completion confirmation message, the corresponding request processing entry is updated according to the transaction identifier, and the suspension is lifted according to the updated request processing entry index. This results in the local transaction completing early and the subsequent consistency maintenance requests being re-entered and sent in order, thereby reducing the impact of the completion confirmation cross-chip round trip on the transaction tracking and sorting resources occupied by the first home node, improving transaction turnaround efficiency and system throughput, and reducing the risk of consistency order violations caused by simply returning completion confirmation early.

[0099] The transaction processing system in the chip interconnection scenario of the embodiments of this application has been described above from the perspective of modular functional entities. The chip system in the embodiments of this application will be described below from the perspective of hardware processing.

[0100] It should be noted that this application also relates to a chip, which includes at least one processor and an interface circuit. The processor includes multiple vector storage units, and the processor is used to execute instruction and / or data interaction through the interface circuit, causing the chip system to execute the transaction processing method in the chip-to-chip interconnection scenario of any of the above embodiments. In one possible implementation, the chip may also directly include a memory storing computer programs or computer instructions.

[0101] For example, the memory can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).

[0102] This application also relates to a processor, which includes a plurality of storage units for calling computer programs or computer instructions stored in the memory to cause the processor to execute the methods described in any of the above embodiments.

[0103] For example, in the embodiments of this application, the processor is an integrated circuit chip with signal processing capabilities. For instance, the processor may be an FPGA, a general-purpose processor, a DSP, an ASIC, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, a SoC, a CPU, a network processor (NP), a microcontroller unit (MCU), a PLD, or other integrated chips, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. In one possible implementation, the embodiments of this application also provide a computer-readable storage medium storing program code, which, when executed on the computer, causes the computer to perform the above-described method embodiments.

[0104] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0106] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, apparatuses, or modules, and may be electrical, mechanical, or other forms.

[0107] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0108] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0109] In the above embodiments, the implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product.

[0110] The computer program product includes one or more computer instructions. When the computer program is loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0111] The technical solutions provided in the embodiments of this application have been described in detail above. Specific examples have been used in the embodiments of this application to illustrate the principles and implementation methods of the embodiments of this application. The description of the above embodiments is only for the purpose of helping to understand the methods and core ideas of the embodiments of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments of this application. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this application.

Claims

1. A transaction processing method in a chip interconnection scenario, characterized in that, The method is applied to a first interface proxy in a first chip, the first chip further including a first home node, and a second chip including a second interface proxy and a second request node. The method includes: Receive the target transaction sent via the second interface proxy, allocate a request processing entry to the target transaction, and forward the target transaction to the first home node; After receiving the completion response from the first home node and having already sent the completion response to the second chip, if no actual completion confirmation message is received from the second chip, a first completion confirmation message is sent to the first home node. Upon receiving a subsequent consistency maintenance request from the first home node, the request processing entries are matched based on the address information and target source node identifier of the subsequent consistency maintenance request to identify whether there are any associated transactions that have sent the first completion confirmation message but have not yet received the actual completion confirmation message. When the associated transaction is identified, the subsequent consistency maintenance request is suspended, and the request processing entry index corresponding to the associated transaction is recorded to prevent the subsequent consistency maintenance request from being sent to the second chip during the suspension period. Upon receiving the actual completion confirmation message returned by the second chip, the corresponding request processing entry is updated according to the transaction identifier, and the pending state of the corresponding subsequent consistency maintenance request is released according to the updated request processing entry index, so that the subsequent consistency maintenance request can be re-entered for transmission.

2. The transaction processing method according to claim 1, characterized in that, The step of sending a first completion confirmation message to the first home node when no actual completion confirmation message is received from the second chip includes: Determine whether the target transaction is a transaction carrying the expected completion confirmation attribute; If the target transaction is a transaction carrying a completion confirmation expectation attribute, and the first interface agent has received the completion response returned by the first home node and has sent the completion response to the second chip, then the first completion confirmation message is sent to the first home node.

3. The transaction processing method according to claim 2, characterized in that, After determining whether the target transaction is a transaction carrying a completion confirmation expectation attribute, the method further includes: Determine whether the target transaction is an ordered write observation request; If the target transaction is determined to be an ordered write observation request, the first interface proxy is prohibited from sending the first completion confirmation message to the first home node before receiving the actual completion confirmation message; After receiving the actual completion confirmation message returned by the second chip, a completion confirmation message is sent to the first home node.

4. The transaction processing method according to claim 1, characterized in that, Assigning a request processing entry to the target transaction includes: The completion confirmation request status of the target transaction is recorded in the request processing entry; When sending the completion response to the second chip, update the completion response sending status of the request processing entry; Upon receiving a completion response from the first home node, update the completion response reception status of the request processing entry; Upon receiving the actual completion confirmation message returned by the second chip, update the actual completion confirmation reception status of the request processing entry.

5. The transaction processing method according to claim 1, characterized in that, The matching of request processing entries based on the address information and target source node identifier of the subsequent consistency maintenance request to identify whether there are any associated transactions that have sent the first completion confirmation message but have not yet received the actual completion confirmation message includes: If the subsequent consistency maintenance request is a snooping request initiated against the second requesting node, obtain the address information and target source node identifier of the snooping request; The address information and the target source node identifier are compared with the address information and source node identifier recorded in each of the request processing entries; The associated transaction is identified when a request processing entry meets the following conditions: The address information recorded in the request processing entry matches the address information of the eavesdropping request; and, The source node identifier recorded in the request processing entry matches the target source node identifier of the eavesdropping request; and, The target transaction corresponding to the request processing entry has sent a completion response to the second chip; and... The target transaction corresponding to the request processing entry needs to return a completion confirmation message; and... The target transaction corresponding to the request processing entry has not yet received the actual completion confirmation message returned by the second chip.

6. The transaction processing method according to claim 5, characterized in that, The step of suspending the subsequent consistency maintenance request and recording the request processing entry index corresponding to the associated transaction includes: Assign consistency maintenance processing entries to the subsequent consistency maintenance requests; Write the subsequent consistency maintenance request into the consistency maintenance processing entry; Set a hazard flag in the consistency maintenance process entry; Write the index of the request processing entry corresponding to the associated transaction into the associated field of the consistency maintenance processing entry; Based on the aforementioned hazard flag, the consistency maintenance process entry is removed from the arbitration process, thereby suspending the subsequent consistency maintenance request.

7. The transaction processing method according to claim 6, characterized in that, The step of updating the corresponding request processing entry according to the transaction identifier and releasing the suspended state of the corresponding subsequent consistency maintenance request according to the index of the updated request processing entry includes: Based on the transaction identifier carried in the actual completion confirmation message, locate the request processing entry corresponding to the actual completion confirmation message; Update the actual completion confirmation receipt status of the request processing entry; Match the associated fields of each consistency maintenance processing entry with the updated request processing entry index; When the associated field of a consistency maintenance entry matches the index of the updated request processing entry, clear the hazard flag of that consistency maintenance entry. After the hazard flag is cleared, the corresponding subsequent consistency maintenance request is re-entered for arbitration.

8. The transaction processing method according to claim 5, characterized in that, After matching the request processing entries based on the address information and target source node identifier of the subsequent consistency maintenance request, the process further includes: Determine whether the same subsequent consistency maintenance request matches multiple request processing entries simultaneously; If the determination result is yes, then the subsequent consistency maintenance request's pending association establishment or sending process is blocked; When only one related transaction remains among the multiple request processing entries, an association is established between the subsequent consistency maintenance request and the request processing entry corresponding to the unique related transaction.

9. A transaction processing system for chip-to-chip interconnection scenarios, characterized in that, The system includes a first chip and a second chip; wherein... The second interface proxy of the second chip is configured to send the target transaction initiated by the second requesting node to the first interface proxy, and forward the completion response returned by the first interface proxy to the second requesting node; The first interface agent of the first chip is configured to receive the target transaction sent through the second interface agent, allocate a request processing entry for the target transaction, and forward the target transaction to the first home node; after receiving the completion response returned by the first home node and having sent a completion response to the second interface agent, if no actual completion confirmation message is received from the second chip, a first completion confirmation message is sent to the first home node. The first home node of the first chip is configured to process the target transaction and return a completion response, as well as issue subsequent consistency maintenance requests during subsequent processing. The second request node of the second chip is configured to return an actual completion confirmation message to the first interface agent after receiving the completion response; The first interface proxy is also configured to, upon receiving a subsequent consistency maintenance request from the first home node, match the request processing entries based on the address information and target source node identifier of the subsequent consistency maintenance request to identify whether there are any associated transactions that have sent a first completion confirmation message but have not yet received an actual completion confirmation message; when an associated transaction is identified, the subsequent consistency maintenance request is written into the consistency maintenance processing tracker and set to suspension, and the index of the request processing entry corresponding to the associated transaction is recorded; when an actual completion confirmation message is received, the corresponding request processing entry is updated according to the transaction identifier, and the suspension state of the corresponding subsequent consistency maintenance request is released according to the updated request processing entry index, so that the subsequent consistency maintenance request can be re-entered for transmission.

10. A chip, characterized in that, The chip includes a processor coupled to a transceiver for executing a transaction processing method in a chip interconnect scenario as described in any one of claims 1-8.

Images