Transaction processing method of a multi-core processor, multi-core processor and electronic device

Abstract

The application discloses a transaction processing method of a multi-core processor, a multi-core processor and electronic equipment, and relates to the technical field of cache coherency of the multi-core processor. In the method, the combined data packet is sent to a destination. Compared with a one-by-one data packet transmission mode, the transmission pressure of an on-chip interconnection network is reduced, thereby reducing the overhead of cache coherency maintenance; secondly, for read-write transactions of multiple continuous cache line addresses, the operation code of the target protocol is configured as a read-write transaction identifier, and the address field of the target protocol is configured as a read-write transaction address, thereby generating the combined data packet. For multiple invalid monitoring request transactions, the destination node identifiers of the multiple invalid monitoring request transactions are combined in the target protocol, thereby generating the combined data packet. In addition, the operation code of the target protocol is used to realize read-write operations on continuous cache line addresses, and the existing protocol read-write transaction data packet structure is kept unchanged.

Description

Technical Field

[0001] This invention relates to the field of multi-core processor cache coherency technology, and in particular to a transaction processing method for a multi-core processor, a multi-core processor, and an electronic device. Background Technology

[0002] Network on Chip (NoC) is a core component of multi-core processor design. It efficiently connects processor cores, memory, and other hardware resources, enabling high-efficiency and scalable on-chip communication. As the number of processor cores increases, maintaining cache coherence between processor core private caches becomes increasingly difficult, placing greater pressure on NoC for data transfer. Current on-chip cache coherence protocols (such as the Coherent Hub Interface (CHI) protocol) can be applied to various interconnect architectures, including Ring, Xbar, and NoC.

[0003] However, the cache coherence protocol has not been specifically optimized for the Mesh-type NoC architecture widely used by the Central Processing Unit (CPU). That is, it has not been optimized for the transmission characteristics of Mesh-type NoC, which leads to increased transmission pressure on NoC in some scenarios (such as read-write transaction processing of multiple consecutive cache line addresses and processing of multiple invalidation listener requests), and the overhead of cache coherence maintenance is correspondingly increased.

[0004] Therefore, how to reduce the transmission pressure of NoC, thereby reducing the overhead of cache consistency maintenance, is a technical problem that urgently needs to be solved by those in the field. Summary of the Invention

[0005] The purpose of this invention is to provide a transaction processing method for multi-core processors, a multi-core processor, and an electronic device to solve the technical problem that the high transmission pressure of NoC leads to increased overhead in cache consistency maintenance.

[0006] To address the aforementioned technical problems, this invention provides a transaction processing method for a multi-core processor, applied at the source end, comprising:

[0007] Acquire the target transaction on a multi-core processor;

[0008] If the target transaction is a read / write transaction for multiple consecutive cache line addresses, then obtain the read / write transaction identifier and the read / write transaction address; configure the opcode of the target protocol as the read / write transaction identifier, and configure the address field of the target protocol as the read / write transaction address to generate a merged data packet; wherein, the opcode includes a reserved field;

[0009] If the target transaction is multiple failure listener request transactions, the destination node identifiers of the multiple failure listener request transactions are merged in the target protocol to generate a merged data packet; wherein, the target protocol is a cache consistency protocol;

[0010] The merged data packet is sent to the destination; wherein the source and the destination are determined based on the transaction type.

[0011] On the one hand, obtaining the read / write transaction identifier includes:

[0012] Obtain the first mapping relationship between the pre-established read / write transaction identifier and the read / write transaction; wherein, the read / write transaction identifier is composed of information from the reserved field in the opcode and information from the remaining field in the opcode;

[0013] The read / write transaction identifier corresponding to the target transaction is determined based on the first mapping relationship.

[0014] On the other hand, configuring the address field of the target protocol as a read / write transaction address includes:

[0015] Configure the address field of the target protocol to the starting address of the consecutive cache line addresses.

[0016] On the other hand, the target transaction is a read transaction in a read-write transaction for multiple consecutive cache line addresses, the source is the target request node, and the destination is the master node;

[0017] After sending the merged data packet to the destination, the process also includes:

[0018] In the master node, the merged data packet is split into multiple read request data packets based on the opcode field and address field in the merged data packet; the directory is queried based on the multiple read request data packets, and a listening data packet is generated to be sent to the request node to be monitored or a read data packet is sent to the slave node according to the cache line status recorded in the directory; the read request response data packets sent by the request node to be monitored or the slave node are obtained, and the read request response data packets are returned to the target request node in sequence; wherein, the destination address in the multiple read request data packets is obtained by offsetting the address field in the merged data packet.

[0019] On the other hand, before the master node sequentially returns the read request response data packet to the target request node, it also includes:

[0020] Obtain the second mapping relationship between the pre-established read transaction identifier and the read transaction of the cache line data fragment; wherein, the read transaction identifier is characterized by the information in the reserved field in the opcode;

[0021] Based on the read transaction of the target cache row data fragment and the second mapping relationship, the opcode in the target read request response data packet is added with the corresponding read transaction identifier to generate the final read request response data packet corresponding to the target cache row data fragment; wherein, the target read request response data packet is the request response data packet corresponding to the target cache row data fragment.

[0022] On the other hand, the target transaction is a write transaction in a read-write transaction for multiple consecutive cache line addresses, the source is the target request node, and the destination is the master node;

[0023] After sending the merged data packet to the destination, the process also includes:

[0024] In the master node, the merged data packet is split into multiple write request data packets according to the opcode field and address field in the merged data packet; and information for receiving write data is sent to the target request node; wherein the destination address in the multiple write request data packets is obtained by offsetting the address field in the merged data packet.

[0025] On the other hand, after the master node sends information indicating the receipt of write data to the target requesting node, it also includes:

[0026] Obtain the third mapping relationship between the pre-established write transaction identifier and the write transaction of the cache line data fragment; wherein, the write transaction identifier is characterized by the information in the reserved field in the opcode;

[0027] Based on the write transaction of the target cache row data fragment and the third mapping relationship, the corresponding write transaction identifier is added to the opcode in the target write request response data packet to generate the final write request response data packet corresponding to the target cache row data fragment; wherein, the target write request response data packet is the request response data packet corresponding to the target cache row data fragment;

[0028] Each of the final write request response data packets is sent to the master node in sequence.

[0029] On the other hand, the source end is the master node; in the target protocol, the destination node identifiers of multiple failed listening request transactions are merged to generate a merged data packet, including:

[0030] In the destination node identifier field of the target protocol, the destination node identifiers of multiple failed listening request transactions are merged. In the flag field of the target protocol, an identifier representing the merged or non-merged listening request is configured. In the quantity field of the target protocol, the number of merged failed listening request transactions is configured to generate a merged listening request data packet.

[0031] Sending the merged data packet to the destination includes:

[0032] The merged listening request data packet is sent to the destination.

[0033] On the other hand, before sending the merged listening request data packet to the destination, it also includes:

[0034] Obtain the pre-defined routing method for the merged listening request data packets;

[0035] The destination to which the merged listening request data packet is to be sent is determined based on the routing method.

[0036] On the other hand, determining the destination to which the merged listening request data packet is to be sent based on routing methods includes:

[0037] If the routing method is detected as the master node sending the merged listening request data packet to the listening relay module, and the listening relay module forwarding the listening request data packet to the corresponding destination node, then the destination to which the merged listening request data packet is to be sent is determined to be the listening relay module.

[0038] On the other hand, after sending the merged listening request data packet to the destination, the process also includes:

[0039] Parse the merged listening request data packet and obtain the parsing result;

[0040] If the flag field in the parsing result is configured to represent the merged listening request, then a corresponding number of listening request data packets are generated according to the number of merged failed listening request transactions configured in the quantity field; wherein, the destination node identifier field in each listening request data packet corresponds to the identifier field of a destination node in the merged listening request data packet.

[0041] The listening request data packets are sent to the corresponding destination node through the listening relay module.

[0042] On the other hand, after the listening request data packets are sent to the corresponding destination node through the listening relay module, the method further includes:

[0043] The monitoring relay module receives monitoring response data packets sent by each destination node; in the destination node identifier field of the target protocol, the node identifiers corresponding to the destination nodes of multiple monitoring responses are merged; in the flag field of the target protocol, an identifier representing the merged monitoring response or the non-merged monitoring response is configured; in the quantity field of the target protocol, the number of merged monitoring responses is configured to generate a merged monitoring response data packet; and the merged monitoring response data packet is sent to the master node.

[0044] On the other hand, determining the destination to which the merged listening request data packet is to be sent based on routing methods includes:

[0045] If the routing method is detected to be that the master node sends the merged listening request data packet to a preset destination node among all destination nodes, and performs the next level transmission according to the destination node in the merged listening request data packet, then the destination is determined to be the preset destination node.

[0046] On the other hand, sending the merged data packet to the destination includes:

[0047] The merged listening request data packet is sent to the preset destination node;

[0048] After sending the merged listening request data packet to the preset destination node, the method further includes:

[0049] In the preset destination node, the merged listening request data packet is parsed, the parsing result is obtained, and the listening information destined for the local node is downloaded from the merged listening request data packet;

[0050] If the flag field in the parsing result contains a configuration representing the merged listening response, then determine whether the number of merged listening responses minus 1 equals 0.

[0051] If so, then confirm that the forwarding of the merged listening request data packet has been completed;

[0052] If not, the value obtained by subtracting 1 from the number of merged listening responses is assigned to the quantity field, and the node identifiers corresponding to each node after the preset destination node in the merged listening request data packet are subtracted by 1 to obtain the information of the new destination node identifier field, so as to generate the new merged listening request data packet.

[0053] The steps include transmitting the new merged listening request data packet to the destination node corresponding to the first destination node identifier in the information of the new destination node identifier field, returning the parsing of the merged listening request data packet and obtaining the parsing result, and downloading the listening information to be sent to the local node from the merged listening request data packet.

[0054] On the other hand, in the destination node identifier field of the target protocol, merging the destination node identifiers of multiple failed listening request transactions includes:

[0055] In the destination node identifier field of the target protocol, the node identifiers corresponding to the destination nodes of multiple listening responses are sorted sequentially according to the routing order.

[0056] On the other hand, it also includes:

[0057] After the destination node obtains the corresponding listening request data packet, it sequentially receives the listening response data packets sent by each destination node.

[0058] To address the aforementioned technical problems, the present invention also provides a multi-core processor, comprising a source end and a destination end;

[0059] The source end is used to obtain the target transaction on the multi-core processor; if the target transaction is a read / write transaction for multiple consecutive cache line addresses, then the read / write transaction identifier and read / write transaction address are obtained; the opcode of the target protocol is configured as the read / write transaction identifier, and the address field of the target protocol is configured as the read / write transaction address to generate a merged data packet; wherein, the opcode includes a reserved field; if the target transaction is multiple failure listening request transactions, then the destination node identifiers of the multiple failure listening request transactions are merged in the target protocol to generate a merged data packet; wherein, the target protocol is a cache consistency protocol; the merged data packet is sent to the destination end; wherein, the source end and the destination end are determined based on the transaction type;

[0060] The destination terminal is used to receive the merged data packets sent by the source terminal.

[0061] To address the aforementioned technical problems, the present invention also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the transaction processing method of the multi-core processor described above.

[0062] To address the aforementioned technical problems, the present invention also provides an electronic device, comprising:

[0063] Memory, used to store computer programs;

[0064] A processor, used to implement the above-described transaction processing method for a multi-core processor when executing the computer program.

[0065] To address the aforementioned technical problems, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the transaction processing method for a multi-core processor described above.

[0066] The beneficial effects of this invention are as follows: First, in this method, different methods are used to generate merged data packets according to different transactions, and then the merged data packets are sent to the destination. Compared with the method of transmitting data packets one by one, the transmission pressure of the on-chip interconnect network is reduced, thereby reducing the overhead of cache consistency maintenance. Second, when the target transaction is a read / write transaction for multiple consecutive cache line addresses, the read / write transaction identifier and read / write transaction address are obtained; the opcode of the target protocol is configured as the read / write transaction identifier, and the address field of the target protocol is configured as the read / write transaction address, generating the merged data packet. When the target transaction is multiple failure listening request transactions, the destination node identifiers of multiple failure listening request transactions are merged in the target protocol to generate the merged data packet, realizing the acquisition of the merged data packet through different methods. Third, the identifier and read / write transaction address for multiple consecutive cache line addresses are newly added to the reserved field in the existing target protocol opcode, realizing the read / write operation of consecutive cache line addresses without changing the existing protocol read / write transaction data packet structure.

[0067] Furthermore, by establishing a first mapping relationship between read / write transaction identifiers and read / write transactions in advance, and determining the target transaction identifier based on this mapping relationship, and by combining the reserved fields and remaining fields of the opcode for the read / write transaction identifier, the uniqueness of the transaction identifier can be guaranteed while enabling fast parsing and matching of the transaction identifier. This eliminates the need to dynamically generate the identifier during transaction execution, reduces runtime overhead, and improves transaction scheduling and processing efficiency. Moreover, the field reuse method can save instruction coding space, and adapting to existing instruction formats does not require significant modifications to hardware or protocols.

[0068] Configuring the address field of the target protocol as the starting address of a consecutive cache line significantly reduces the amount of data in the address field compared to configuring the complete addresses of consecutive cache lines, thereby reducing the overhead of protocol transmission and storage. At the same time, the continuity of cache lines can be utilized to quickly locate the entire cache line using only the starting address, improving the efficiency of address resolution and data access.

[0069] In read transaction scenarios with consecutive cache line addresses, after the merged data packet arrives at the master node, the master node parses the merged data packet. Specifically, based on the opcode and address fields in the merged data packet, it splits the merged data packet into multiple read request data packets (the destination addresses in the multiple read request data packets are obtained by offsetting the address fields in the merged data packet). Based on the multiple read request data packets, the master node queries the directory and generates listening data packets to be listened to or read data packets to be listened to by the slave nodes according to the cache line status recorded in the directory. It also obtains the read request response data packets sent by the listening request nodes or slave nodes. Then, the read request response data packets are returned to the target request nodes sequentially. Since the probability of the cache line status corresponding to each cache line address recorded in the master node directory is different, the listening measures taken for each cache line address are different, and it is difficult to synchronize the return of multiple cache line data. Therefore, the data return response corresponding to the read operation adopts a separate transmission mode, and the separate transmission mode does not change the structure of the data packet.

[0070] Before the master node sequentially returns the read request response packets to the target request node, it adds the corresponding read transaction identifier to the opcode in the target read request response packet based on the read transaction and second mapping relationship between the target cache line data fragment (the mapping relationship between the read transaction identifier and the read transaction of the cache line data fragment), thus generating the final read request response packet corresponding to the target cache line data fragment. That is, data ordering is considered during the read data return response process (the data receiver needs to distinguish the cache line address corresponding to the returned cache line data). The read request packet contains the identifier corresponding to the read transaction of the cache line data fragment, enabling the target request node to determine the cache line address corresponding to the currently received data after receiving the read request response packet.

[0071] In a write transaction scenario with contiguous cached row addresses, after the merged data packet is transmitted to the master node, the master node parses the merged data packet. Specifically, based on the opcode and address fields in the merged data packet, it splits the merged data packet into multiple write request data packets; and sends information indicating the receipt of write data to the target requesting node. The destination address in the multiple write request data packets is obtained by offsetting the address field in the merged data packet, thus realizing the parsing of the merged data packet. Furthermore, the master node responds to the target requesting node, indicating that it is ready to receive write data, enabling the target requesting node to promptly transmit the write data to the master node.

[0072] After the master node sends information indicating the receipt of write data to the target requesting node, the slave node, based on the write transaction and third-party mapping relationship of the target cache line data fragment, adds the corresponding write transaction identifier to the opcode in the target write request response data packet to generate the final write request response data packet corresponding to the target cache line data fragment (the target write request response data packet is the request response data packet corresponding to the target cache line data fragment). This considers data order preservation during the data write-back operation. The final write request response data packet contains the identifier corresponding to the write transaction of the cache line data fragment, allowing the master node to determine the cache line address corresponding to the currently received data after obtaining the final write request response data packet.

[0073] In the scenario of multiple failed listening request transactions, the destination node identifiers of multiple failed listening request transactions are merged in the destination node identifier field of the target protocol. The identifier representing the merged or non-merged listening request is configured in the flag field of the target protocol. The number of merged failed listening request transactions is configured in the quantity field of the target protocol, thereby generating a merged listening request data packet.

[0074] Before sending the merged data packets to the destination, the destination is determined based on routing methods. This ensures that the determined destination matches the actual scenario.

[0075] The routing method involves the master node sending the merged listener request data packets to the listener relay module, which then forwards them to the respective destination nodes. This enables unified management of listener requests from each destination node by the listener relay module. Upon receiving the merged listener request data packets, the listener relay module generates a corresponding number of listener request data packets based on the number of merged failed listener request transactions configured in the quantity field (the destination node identifier field in each listener request data packet corresponds to the identifier field of one destination node in the merged listener request data packet), thus generating multiple listener request data packets based on the merged listener request data packets. After receiving responses from each destination node, the listener relay module merges the listener response data packets and then sends the merged listener response data packets to the master node. Compared to transmitting multiple listener response data packets individually to the master node, this method reduces the load on the on-chip interconnect network because it merges multiple listener response data packets before transmission.

[0076] In this routing method, the master node sends the merged listening request data packet to a preset destination node among all destination nodes. The next level of transmission is then performed based on the destination node identifier in the merged listening request data packet. The master node first sends the merged listening request data packet to the preset destination node, then downloads the listening information destined for the local node from the merged data packet, reassembles the merged listening request data packet, and then performs the next level of transmission based on the first destination node identifier in the data packet, until the number of merged listening responses minus 1 equals 0, thus ensuring that the listening request is sent to the corresponding destination node. In this routing method, the destination node identifiers in the merged listening request data packet are arranged according to the routing order, ensuring that the listening request data packets are transmitted in sequence.

[0077] In addition, the present invention also provides a multi-core processor, a computer program product, an electronic device, and a computer-readable storage medium, which have the same or corresponding technical features as the transaction processing method of the multi-core processor mentioned above, and have the same effects. Attached Figure Description

[0078] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0079] Figure 1 A flowchart illustrating a transaction processing method for a multi-core processor, provided as an embodiment of the present invention;

[0080] Figure 2 A schematic diagram illustrating a conventional monitoring and monitoring response transmission process provided in an embodiment of the present invention;

[0081] Figure 3 This is a schematic diagram of the first type of merged monitoring data packet transmission process provided in an embodiment of the present invention;

[0082] Figure 4 This is a schematic diagram of the second merged monitoring data packet transmission process provided in an embodiment of the present invention;

[0083] Figure 5 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0084] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0085] The core of this invention is to provide a transaction processing method for multi-core processors, a multi-core processor, and an electronic device to solve the technical problem that the high transmission pressure of NoC leads to increased overhead in cache consistency maintenance.

[0086] In multi-core processors, as the number of processor cores gradually increases, maintaining cache coherence between processor core private caches becomes increasingly difficult, placing greater pressure on data transfer within NoC (NoC) architectures. Existing on-chip cache coherence protocols (such as the CHI protocol) can be applied to various interconnect architectures such as Ring, Xbar, and NoC. However, for the Mesh-type NoC architecture widely used in current CPUs, the cache coherence protocol has not been specifically optimized, meaning it has not been optimized for the transmission characteristics of Mesh-type NoCs. This leads to increased cache coherence maintenance overhead in some scenarios. For example, the current protocol's coherent read / write operations target a data granularity of 64 bytes, which is the size of a cache line. However, when a core performs multiple cache line-sized read / write operations on a contiguous address range, the requesting node (RN) needs to continuously send multiple read / write transactions to the target host node (HN), all along the same routing path (under a fixed routing algorithm), increasing the local transmission load on the NoC. For example, the master node records the cache data status in the private cache of each core in the directory module. For read and write requests initiated by the processor core, the master node initiates a listening transaction to the corresponding processor core based on the information in the directory. When initiating an invalidation listening transaction for cache data in a shared state, the master node initiates invalidation listening to all processor cores storing that state data and collects the listening response transactions returned by these processor cores. As the number of processor cores increases, the number of listening transactions that the master node needs to initiate will increase when the above situation occurs, which will affect the effective data transmission on the NoC and increase the transmission pressure on the NoC.

[0087] This invention provides a transaction processing method for multi-core processors and a cache coherence protocol for NoC (NoC) systems. It includes a merged transaction data packet structure and a data packet parsing method for consecutive address read / write operations, as well as a merged transaction data packet structure and a data packet parsing method for multiple cache invalidation monitoring operations in a shared state. Furthermore, it proposes a corresponding routing method for merged transaction data packets for Mesh-type NoCs to reduce the transmission pressure on NoCs and thus reduce the overhead of cache coherence maintenance.

[0088] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The transaction processing method for multi-core processors provided by the present invention is applied to the source end. Corresponding to the source end is the destination end. The source end and destination end are not limited, but determined according to the actual transaction type (i.e., scenario). For example, in a scenario of read / write transactions involving multiple consecutive cache line addresses, the source end can be a request node, and the destination end can be a master node; in a scenario of multiple failure listening request transactions, the source end can be a master node, and the destination end can be a router node, or a listening relay module as described later.

[0089] Figure 1 A flowchart of a transaction processing method for a multi-core processor provided in an embodiment of the present invention is shown below. Figure 1 As shown, the method includes:

[0090] S10: Obtain the target transaction on a multi-core processor;

[0091] S11: Generate merged data packets using different methods depending on the type of the target transaction;

[0092] S12: Send the merged data packet to the destination.

[0093] Specifically, step S11 includes:

[0094] S111: If the target transaction is a read / write transaction for multiple consecutive cache line addresses, then obtain the read / write transaction identifier and read / write transaction address; configure the target protocol's opcode as the read / write transaction identifier and configure the target protocol's address field as the read / write transaction address to generate the merged data packet; wherein, the opcode contains a reserved field;

[0095] S112: If the target transaction consists of multiple failure listener request transactions, the destination node identifiers of the multiple failure listener request transactions are merged in the target protocol to generate a merged data packet.

[0096] On a multi-core processor, the target transaction can be a read / write transaction targeting multiple consecutive cache line addresses, or it can be a transaction targeting multiple cache misses. The target protocol is the cache consistency protocol.

[0097] Considering that within a contiguous address range managed by the same master node, the destination node identifier (ID) in the transaction data packets of requesting nodes performing read and write operations on consecutive cache line addresses is the same, and the memory address information is contiguous, a method for merging the data packets of multiple read or write operation transactions initiated in this scenario is proposed. The following section first describes the merged packet structure for read and write transactions with multiple consecutive cache line addresses and their corresponding data transmissions.

[0098] Table 1. Partial Structure of Request Transaction Datagrams in the CHI Protocol

[0099]

[0100] Here, Addr represents the address field; Size represents the length of the data; Opcode represents the opcode field; and x represents the total length of the entire Addr field.

[0101] According to CHI protocol version F, in the Opcode encoding of a consistency request transaction, the 0x3B-0x3F encoding segment of Opcode[5-0] is in a Reserved state, so 6 additional Opcode encodings can be added to represent new read / write operations. Therefore, in some embodiments, obtaining the read / write transaction identifier includes: obtaining a first mapping relationship between a pre-established read / write transaction identifier and a read / write transaction; wherein, the read / write transaction identifier consists of information from the reserved fields in the opcode and information from the remaining fields in the opcode;

[0102] The read / write transaction identifier corresponding to the target transaction is determined based on the first mapping relationship.

[0103] In addition, to reduce the overhead of protocol transmission and storage, in implementation, configuring the address field of the target protocol as the read / write transaction address includes configuring the address field of the target protocol as the starting address of a consecutive cache line address.

[0104] Table 2 Read / Write Transaction Identifier Table

[0105]

[0106] Where D is short for Double, indicating an operation on data corresponding to two consecutive cache line addresses; Q is short for Quadruple, indicating an operation on data corresponding to four consecutive cache line addresses. Specifically, ReadShareD indicates a ReadShare operation on data corresponding to two consecutive cache line addresses; ReadUniqueD indicates a ReadUnique operation on data corresponding to two consecutive cache line addresses; ReadShareQ indicates a ReadShare operation on data corresponding to four consecutive cache line addresses; ReadUniqueQ indicates a ReadUnique operation on data corresponding to four consecutive cache line addresses; WriteBackFullD indicates a WriteBackFull operation on data corresponding to two consecutive cache line addresses; WriteBackFullQ indicates a WriteBackFull operation on data corresponding to four consecutive cache line addresses. In read / write transactions involving multiple consecutive cache line addresses, the Addr field (i.e., the domain segment) represents the starting address of the consecutive cache line addresses.

[0107] This method achieves read and write operations on consecutive cache line addresses by adding a merged read and write operation encoding to the Opcode field in the read and write operation transaction data packets, without changing the existing protocol read and write transaction data packet structure. It pre-establishes a first mapping relationship between read and write transaction identifiers and read and write transactions, and determines the target transaction identifier based on this mapping relationship. The read and write transaction identifier is composed of reserved fields and remaining fields of the opcode, ensuring the uniqueness of the transaction identifier while enabling rapid parsing and matching of the transaction identifier. This eliminates the need for dynamic identifier generation during transaction execution, reducing runtime overhead and improving transaction scheduling and processing efficiency. Furthermore, the field reuse method saves instruction encoding space, and adaptation to existing instruction formats does not require significant hardware or protocol modifications. Configuring the target protocol's address field as the starting address of the consecutive cache line addresses significantly reduces the amount of data in the address field compared to configuring the complete addresses of consecutive cache lines, reducing protocol transmission and storage overhead. Simultaneously, it leverages the continuity of cache lines, allowing rapid location of the entire cache line using only the starting address, improving the efficiency of address resolution and data access.

[0108] In the above method, a merged data packet is generated for read / write transactions involving multiple consecutive cache line addresses. The requesting node sends the merged data packet to the master node, which then needs to further process the merged data packet in response to the request.

[0109] Read and write transactions involving multiple consecutive cache line addresses specifically include read transactions involving multiple consecutive cache line addresses and write transactions involving multiple consecutive cache line addresses.

[0110] The following section describes the processing of the master node after the merged data packet arrives in the scenario of read transactions with consecutive cached row addresses. Specifically, it explains the parsing and transmission methods for read merged transaction data packets with multiple consecutive cached row addresses.

[0111] The target transaction is a read transaction within a read-write transaction that targets multiple consecutive cache line addresses. The source is the target request node, and the destination is the master node.

[0112] After sending the merged data packets to the destination, the process also includes:

[0113] In the master node, based on the opcode field and address field in the merged data packet, the merged data packet is split into multiple read request data packets; based on the multiple read request data packets, the directory is queried, and based on the cache line status recorded in the directory, a listening data packet is generated to be sent to the request node to be listened to or a read data packet is sent to the slave node, and the read request response data packets sent by the request node to be listened to or the slave node are obtained, and the read request response data packets are returned to the target request node in sequence; wherein, the destination address in the multiple read request data packets is obtained by offsetting the address field in the merged data packet.

[0114] Specifically, after receiving the merged data packet, the receiving end (master node) first parses the Opcode field in the data packet. If the Opcode is for a non-merged transaction data packet, it is processed according to the normal transaction data packet processing procedure. If the Opcode is for a merged transaction data packet, the merged transaction data packet is split according to the Opcode and the Addr field in the merged data packet. For example, if the master node receives a ReadShareD transaction, it splits it into two ReadShare transactions for processing. The address of one ReadShare transaction is the Addr field information, and the address of the other ReadShare transaction is the Addr field information + 6'b100000, which represents the address of the next cache line consecutive to the Addr information in the data packet.

[0115] Considering that the probability of the cache line status corresponding to each cache line address recorded in the master node directory is different, resulting in different listening measures for each cache line address, it is difficult to synchronize the return of multiple cache line data. Therefore, in this embodiment, the data return response corresponding to the read operation adopts a separate transmission mode, and adopting a separate transmission mode will not change the structure of the data packet.

[0116] Furthermore, the order preservation of data is considered during the read data return response process; that is, the data receiver needs to identify the cache line address corresponding to the returned cache line data. Therefore, in some embodiments, before the master node sequentially returns the read request response data packet to the target request node, it also includes:

[0117] Obtain the second mapping relationship between the pre-established read transaction identifier and the read transaction of the cached row data fragment; wherein, the read transaction identifier is characterized by the information in the reserved field in the opcode;

[0118] Based on the read transaction and second mapping relationship of the target cache row data fragment, the corresponding read transaction identifier is added to the opcode in the target read request response data packet to generate the final read request response data packet corresponding to the target cache row data fragment; wherein, the target read request response data packet is the request response data packet corresponding to the target cache row data fragment.

[0119] Specifically, in the CHI protocol, the data return response for a read operation is CompDate, and the data write-back operation for WriteBackFull is CopyBackWrData. Based on this, six fields in the Reserved state are redefined, and six new data channel Opcode encodings are added to preserve the order of cached line data. Table 3 shows the second mapping relationship (the content corresponding to read data) and the third mapping relationship (the content corresponding to write data), which will be described later.

[0120] Table 3. Mapping Relationship between Transaction Identifiers and Transaction Sharding of Cached Row Data.

[0121]

[0122] In this embodiment, before the master node sequentially returns the read request response data packet to the target request node, it adds the corresponding read transaction identifier to the opcode in the target read request response data packet based on the read transaction and second mapping relationship between the target cache line data fragment (the mapping relationship between the read transaction identifier and the read transaction of the cache line data fragment), thereby generating the final read request response data packet corresponding to the target cache line data fragment. That is, data order preservation is considered during the read data return response process (the data receiver needs to distinguish the cache line address corresponding to the returned cache line data). The read request data packet contains the identifier corresponding to the read transaction of the cache line data fragment, so that the target request node can determine the cache line address corresponding to the currently received data after obtaining the read request response data packet.

[0123] The preceding text provided a detailed explanation of the master node's processing procedures after the merged data packets arrive at the master node in a read transaction scenario with consecutive cached line addresses. This embodiment provides a detailed explanation of the master node's processing procedures after the merged data packets arrive at the master node in a write transaction scenario with consecutive cached line addresses, specifically describing the parsing and transmission methods for write merged transaction data packets with multiple consecutive cached line addresses.

[0124] In practice, the target transaction is a write transaction within a read-write transaction that targets multiple consecutive cache line addresses, with the source being the target request node and the destination being the master node.

[0125] After sending the merged data packets to the destination, the process also includes:

[0126] In the master node, the merged data packet is split into multiple write request data packets based on the opcode field and address field in the merged data packet; and information representing the receipt of write data is sent to the target request node; wherein, the destination address in the multiple write request data packets is obtained by offsetting the address field in the merged data packet.

[0127] Specifically, after receiving the merged data packet, the receiving end (master node) first parses the Opcode field in the data packet. If the Opcode is a non-merged transaction data packet, it is processed according to the normal transaction data packet processing procedure. If the Opcode is a merged transaction data packet, the merged transaction data packet is split according to the Opcode and Addr field in the merged data packet, and the addresses of other data packets are calculated based on the starting address in Addr. Then, the master node sends a CompDBIDResp response to the requesting node, indicating that it is ready to receive data.

[0128] The write-back operation corresponding to the write transaction also adopts a separate transmission mode. However, this mode requires maintaining the order of data, that is, the data receiver needs to distinguish the cache line address corresponding to the currently received data. Therefore, in some embodiments, after the master node sends information indicating the receipt of write data to the target requesting node, it also includes:

[0129] Obtain the third mapping relationship between the pre-established write transaction identifier and the write transaction of the cache line data fragment (see Table 3 described above); wherein, the write transaction identifier is represented by the information in the reserved field in the opcode;

[0130] Based on the write transaction and third mapping relationship of the target cache row data fragment, the corresponding write transaction identifier is added to the opcode in the target write request response data packet to generate the final write request response data packet corresponding to the target cache row data fragment; wherein, the target write request response data packet is the request response data packet corresponding to the target cache row data fragment;

[0131] Each final write request response data packet is sent to the master node in sequence.

[0132] In the method provided in this embodiment, after the master node sends information representing the receipt of write data to the target requesting node, the slave node adds a corresponding write transaction identifier to the opcode in the target write request response data packet based on the write transaction and third mapping relationship of the target cache line data fragment, thereby generating the final write request response data packet corresponding to the target cache line data fragment (the target write request response data packet is the request response data packet corresponding to the target cache line data fragment). That is, data order preservation is considered during the data write-back operation. The final write request response data packet contains the identifier corresponding to the write transaction of the cache line data fragment, so that the master node can determine the cache line address corresponding to the currently received data after obtaining the final write request response data packet.

[0133] The preceding text described the process of merging, parsing, and transmitting data packets in a read / write transaction scenario involving contiguous cache line addresses. Considering that key information such as memory address information and target cache data state transition information are identical in the failure listener data packets initiated by the master node to multiple processor cores with shared cache data, differing only in the destination node ID, a method for merging multiple failure listener data packets initiated in this scenario is proposed, along with merging the subsequent multiple listener response data packets. The following section explains the process of merging, parsing, and transmitting data packets in a scenario involving multiple failure listener request transactions.

[0134] First, the merging of data packets from multiple failed listening requests at the same address and the data packet structure are explained. In some embodiments, the source end is the master node; merging the destination node identifiers of multiple failed listening request transactions in the target protocol to generate a merged data packet includes: merging the destination node identifiers of multiple failed listening request transactions in the destination node identifier field of the target protocol; configuring an identifier representing a merged or non-merged listening request in the flag field (Flag) of the target protocol; and configuring the number of merged failed listening request transactions in the quantity field (Num[q:0]) of the target protocol to generate a merged listening request data packet.

[0135] Sending the merged data packet to the destination includes sending the merged listening request data packet to the destination.

[0136] Table 4. Partial Field Contents of the Merged Listening Request Data Packet

[0137]

[0138] This data packet adds fields indicating whether it is a merged listening request and the number of merged requests to the original listening transaction and listening response data packets. It also expands the original destination ID field, as shown in Table 4 as an example of the merged listening request data packet field. The Flag field indicates whether it is a merged listening request; Num[q:0] indicates how many listening request data packets the packet consists of, where the value of q is related to the number of processor cores in each region. The maximum number of merged listening data packets can be achieved by ensuring that this field has enough bits to represent the number of processor cores; the TgtRegID field represents the ID information of the target region of the merged data packet, used for routing the merged listening data packets, where [n:0] represents a bit field; the TgtID field represents the ID of the destination node, where the value of p is equal to the number of processor cores in each region, and the value of m is the same as the number of bits in the destination node ID specified in the cache coherence interconnect protocol used.

[0139] In this embodiment, in the scenario of multiple failed listening request transactions, the destination node identifiers of multiple failed listening request transactions are merged in the destination node identifier field of the target protocol, an identifier representing the merged listening request or the non-merged listening request is configured in the flag field of the target protocol, and the number of merged failed listening request transactions is configured in the quantity field of the target protocol, thereby generating a merged listening request data packet.

[0140] In scenarios involving multiple failed listener request transactions, to ensure the determined destination matches the actual scenario, the process includes the following steps before sending the merged listener request data packet to the destination:

[0141] Obtain the pre-defined routing method for the merged listening request data packets;

[0142] The destination to which the merged listening request data packet is to be sent is determined based on the routing method.

[0143] In some embodiments, determining the destination to which the merged listening request data packet is to be sent based on routing methods includes:

[0144] If the routing method detects that the master node sends the merged listening request data packet to the listening relay module, and the listening relay module forwards the listening request data packet to the corresponding destination node, then the destination to which the merged listening request data packet is to be sent is determined to be the listening relay module. This data packet transmission method based on the current routing method is called the first merged listening data packet transmission method.

[0145] After receiving the merged listening request data packet, the listening relay module parses and transmits it to ensure that each destination node can respond to the listening request. Specifically, after sending the merged listening request data packet to the destination, it also includes:

[0146] Parse the merged listener request data packets and obtain the parsing results;

[0147] If the flag field in the parsing result is configured to represent the merged listener request, then a corresponding number of listener request data packets are generated according to the number of merged failed listener request transactions configured in the quantity field; wherein, the destination node identifier field in each listener request data packet corresponds to the identifier field of a destination node in the merged listener request data packet.

[0148] The listening relay module sends each listening request data packet to the corresponding destination node.

[0149] Furthermore, after the listening request data packets are sent to the corresponding destination node via the listening relay module, the process also includes:

[0150] The monitoring relay module receives monitoring response data packets sent by each destination node; in the destination node identifier field of the target protocol, the node identifiers corresponding to the destination nodes of multiple monitoring responses are merged; in the flag field of the target protocol, an identifier representing the merged or non-merged monitoring response is configured; in the quantity field of the target protocol, the number of merged monitoring responses is configured to generate a merged monitoring response data packet; and the merged monitoring response data packet is sent to the master node.

[0151] Table 5. Partial Field Contents of the Merged Listening Response Data Packet

[0152]

[0153] This data packet adds fields indicating whether it is a merged listener response and the number of merged packets to the original listener transaction and listener response data packets, and expands the original destination ID field. In Table 5, the Flag field indicates whether it is a merged listener response; Num[q:0] indicates how many listener response data packets the packet consists of; the TgtID field indicates the ID information of the master node of the merged listener response data packet, used for routing the merged listener response data packet, where [n:0] represents a bit field; the SrcID field indicates the ID of the processor core (i.e., the destination node) that initiated the listener response. The listener response merged data packet is assembled and sent by the listener relay module.

[0154] In this embodiment, the routing method involves the master node sending the merged listening request data packet to the listening relay module, which then forwards it to each destination node. By partitioning the on-chip interconnect network, all listening transactions sent by the master node to processor cores within the same region are merged into a single listening request. When this request reaches the target region, the module responsible for handling listening and merging / decomposing listening responses (the listening relay module) decomposes the listening request into a corresponding number of listening requests and sends them to the target processor core. Similarly, listening responses returned by processor cores within the same region are first sent to the listening relay module, which merges these responses into a single listening response before sending it to the master node. This significantly reduces the number of listening requests and responses, improves the efficiency of cache consistency maintenance within multi-core processors, and reduces the data transmission pressure on NoC.

[0155] In addition to the routing method mentioned above for data transmission (i.e., the first method for merging and transmitting listening data packets), this embodiment also provides another routing method for data transmission (i.e., the second method for merging and transmitting listening data packets). The destination to which the merged listening request data packet is to be sent is determined based on the routing method, including:

[0156] If the routing method is detected so that the master node sends the merged listening request data packet to a preset destination node among all destination nodes, and the next level of transmission is performed according to the destination node in the merged listening request data packet, then the destination is determined to be the preset destination node.

[0157] Sending the merged data packet to the destination includes: sending the merged listening request data packet to the preset destination node;

[0158] After sending the merged listening request data packet to the preset destination node, it also includes:

[0159] In the preset destination node, the merged listening request data packet is parsed, the parsing result is obtained, and the listening information to be sent to the local node is downloaded from the merged listening request data packet;

[0160] If the flag field in the parsing result contains a configuration representing the merged listening response, then determine whether the number of merged listening responses minus 1 equals 0.

[0161] If so, then confirm that the forwarding of the merged listening request data packet has been completed;

[0162] If not, the value obtained by subtracting 1 from the number of merged listening responses is assigned to the quantity field, and the node identifiers of each node after the preset destination node in the merged listening request data packet are subtracted by 1 to obtain the information of the new destination node identifier field, so as to generate a new merged listening request data packet.

[0163] The process involves transmitting the new merged listening request data packet to the destination node corresponding to the first destination node identifier in the new destination node identifier field, returning the parsed merged listening request data packet and obtaining the parsing result, as well as downloading the listening information destined for the local node from the merged listening request data packet.

[0164] Furthermore, in the destination node identifier field of the target protocol, merging the destination node identifiers of multiple failed listening request transactions includes: in the destination node identifier field of the target protocol, sorting the node identifiers corresponding to the destination nodes of multiple listening responses sequentially according to the routing order. After the destination node obtains the corresponding listening request data packet, it sequentially receives the listening response data packets sent by each destination node.

[0165] In this embodiment, the routing method involves the master node sending the merged monitoring request data packet to a preset destination node among all destination nodes, and then proceeding to the next level of transmission based on the destination node in the merged monitoring request data packet. The master node first sends the merged monitoring request data packet to the preset destination node, then downloads the monitoring information destined for the local node from the merged data packet, reassembles the merged monitoring request data packet, and then proceeds to the next level of transmission based on the first destination node identifier in the data packet, until the number of merged monitoring responses minus 1 equals 0, thus achieving the transmission of the monitoring request to the corresponding destination node. In this routing method, the destination node identifiers in the merged monitoring request data packet are arranged according to the routing order, ensuring that the monitoring request data packets are transmitted in sequence.

[0166] To enable those skilled in the art to better understand the processing procedure for multiple failure monitoring requests at the same address provided by this invention, the procedure will be described again below with reference to the accompanying drawings and specific embodiments.

[0167] Figure 2 This is a schematic diagram illustrating a conventional monitoring and monitoring response transmission process provided in an embodiment of the present invention. Figure 2 In the example, assuming the master node needs to send... Figure 2 If the cache of the four processor cores (referred to as cores) sends a listening request, the master node needs to generate 4 listening request data packets, which are routed through the on-chip interconnect network (composed of multiple routers 1) (taking XY routing as an example) to the 4 target processor cores. After the processor cores have processed the listening request, they return a listening response. At this time, a total of 4 listening response data packets will be generated, which are routed back to the master node through the on-chip interconnect network. Figure 2 In the diagram, ① represents the transmission path of the listening request data packet, and ② represents the transmission path of the listening response data packet.

[0168] To reduce the load on the on-chip interconnect network, Figure 3This is a schematic diagram of the first type of merged monitoring data packet transmission process provided in an embodiment of the present invention, as shown below. Figure 3 As shown, it is still assumed that the master node needs to send... Figure 3 The caches of the four processor cores in the system send listener requests. These four processor cores are divided into the same region. At this time, the master node will generate a merged listener request data packet. According to the TgtRegID information in the data packet, it is routed through the on-chip interconnect network to the listener relay module (hereinafter referred to as the module) in the target region. The listener relay module decomposes the merged listener data packet into four listener request data packets and sends them to the four processor cores in the region respectively. Similarly, after the processor cores have processed the listener requests, the resulting listener responses first reach the listener relay module, which then merges the information of the four listener responses into a single listener response data packet and sends it to the master node. Figure 3 In this diagram, ① indicates that the master node sends the merged listening request data packet to the listening relay module via the router connected to the listening relay module; ② indicates that the listening relay module splits the merged listening request data packet into four listening request data packets and then sends the four listening request data packets to the corresponding processor cores; ③ indicates that the four processor cores each send their listening response data packets to the listening relay module; the listening relay module merges the four received listening response data packets to generate a merged listening response data packet; and ④ indicates that the listening relay module sends the merged listening response data packet to the master node.

[0169] The parsing process of the receiving end for merged monitoring data packets varies depending on the routing method of the monitoring request data packets within the area. Figure 3 In this routing method, the process by which the listening relay module generates multiple listening request packets based on the information in the merged listening data packets (i.e., the packet parsing process) is as follows: When the listening relay module receives the listening channel data packet, it first parses the Flag field. If the Flag is 0, it is forwarded according to the normal listening transaction; if the Flag is 1, it generates a corresponding number of listening data packets based on the value of Num[q:0]. The Opcode, Addr, and other field information in these data packets are the same as the corresponding field information in the merged listening request data packet. The TgtID field information is copied sequentially from TgtID0, TgtID1, ..., etc., in the merged listening request data packet, that is, a merged listening transaction is split into multiple listening transactions and routed to their respective destination nodes. In this case, only one listening relay module can be configured in the unified area.

[0170] Figure 4 This is a schematic diagram of the second type of merged monitoring data packet transmission process provided in an embodiment of the present invention, as shown below. Figure 4 As shown, it is still assumed that the master node needs to send... Figure 4The caches of the four processor cores in the chip send listener requests. These four processor cores are divided into the same region. At this time, the master node will generate a merged listener request packet. According to the TgtRegID information in the packet, it is routed through the on-chip interconnect network to the first routing node in the target region. According to the information in the merged listener packet, the listener information destined for the local node is downloaded from the merged listener packet, and the merged listener packet is reassembled. Then, according to TgtID0 in the packet, the next level of transmission is performed until the value of Num[q:0]-1 in the merged listener packet is 0. After the processor cores have processed the listener request, they return a listener response. At this time, a total of 4 listener response packets will be generated, which are routed through the on-chip interconnect network to the master node. Figure 4 ① In this diagram, the master node sends the merged listener request packet to the first routing node. The first routing node, based on the information in the merged listener packet, downloads the listener information destined for its local node from the merged packet and reassembles the merged listener packet. ② In this diagram, the first routing node sends the new merged listener request packet to the second routing node. The second routing node repeats the actions of the first routing node, and then sends the new merged listener request packet to the third routing node, repeating the above process until all processor cores have received the listener request packet. ③ In this diagram, each of the four processor cores sends its listener response packet to the master node.

[0171] exist Figure 4 In this routing method, the packet parsing process is as follows: When the first destination node receives the listening channel packet, it first parses the Flag field. If Flag is 0, it forwards the packet according to the normal listening transaction. If Flag is 1, it assembles the Opcode, Addr, and other field information from the merged listening packet into a packet according to the format of a non-merged listening packet and sends it to the requesting node for node interconnection. At the same time, if the value of Num[q:0]-1 is not 0, it assigns the value of Num[q:0]-1 to the Num[q:0] field, and assigns the value of TgtID1 to the TgtID0 field, the value of TgtID2 to the TgtID1 field, and so on. This ensures that the value of the TgtID0 field always serves as the destination node ID of the merged listening request packet, and the merged listening request packet continues to be forwarded to the destination node. If the value of Num[q:0]-1 is 0, it indicates that the final destination of the merged listening request packet is this node, and the merged packet is no longer forwarded. Under this rule, when the master node merges listening request data packets, the order of TgtIDs must strictly follow the order in which the data packets arrive at the target node IDs under the fixed routing algorithm.

[0172] The cache coherence protocol for on-chip interconnect networks provided by this invention includes a merged transaction data packet structure and a data packet parsing method for consecutive address read and write operations, as well as a merged transaction data packet structure and a data packet parsing method for multiple cache data invalidation monitoring operations in a shared state. Furthermore, a corresponding routing method for merged transaction data packets for Mesh-type on-chip interconnect networks is proposed, which reduces the transmission pressure of on-chip interconnect networks and effectively reduces the overhead of cache coherence maintenance.

[0173] The foregoing described a transaction processing method using a multi-core processor. This embodiment also provides a multi-core processor. The multi-core processor provided in this embodiment includes a source end and a destination end;

[0174] The source end is used to obtain the target transaction on the multi-core processor; if the target transaction is a read / write transaction for multiple consecutive cache line addresses, it obtains the read / write transaction identifier and read / write transaction address; it configures the opcode of the target protocol as the read / write transaction identifier and the address field of the target protocol as the read / write transaction address to generate a merged data packet; wherein, the opcode contains a reserved field; if the target transaction is multiple failure listener request transactions, it merges the destination node identifiers of the multiple failure listener request transactions in the target protocol to generate a merged data packet; wherein, the target protocol is a cache consistency protocol; the merged data packet is sent to the destination end; wherein, the source end and the destination end are determined based on the transaction type;

[0175] The destination is used to receive the merged data packets sent by the source.

[0176] The multi-core processor provided in this embodiment has the same or corresponding technical features as the transaction processing method of the multi-core processor described above. The embodiments of the transaction processing method of the multi-core processor have been described in detail above, and the embodiments of the multi-core processor will not be repeated here, and the effects are the same as above.

[0177] In the above embodiments, the transaction processing method for multi-core processors has been described in detail. This invention also provides embodiments of transaction processing apparatus and electronic devices for multi-core processors. It should be noted that this invention describes the apparatus embodiments from two perspectives: one based on functional modules, and the other based on hardware.

[0178] The multi-core processor transaction processing apparatus provided in the embodiments of the present invention, based on the perspective of functional modules, includes:

[0179] The acquisition module is used to acquire target transactions on multi-core processors;

[0180] The generation module is used to generate merged data packets using different methods depending on the type of the target transaction.

[0181] The sending module is used to send the merged data packets to the destination.

[0182] Specifically, the generation module includes:

[0183] The first generation module is used to obtain the read / write transaction identifier and read / write transaction address if the target transaction is a read / write transaction for multiple consecutive cache line addresses; configure the opcode of the target protocol as the read / write transaction identifier and configure the address field of the target protocol as the read / write transaction address to generate the merged data packet; wherein, the opcode contains a reserved field;

[0184] The second generation module is used to merge the destination node identifiers of multiple failed listener request transactions in the target protocol to generate a merged data packet if the target transaction consists of multiple failed listener request transactions.

[0185] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0186] Figure 5 This is a structural diagram of an electronic device provided in an embodiment of the present invention. This embodiment is based on a hardware perspective, such as... Figure 5 As shown, the electronic device includes:

[0187] Memory 20 is used to store computer programs;

[0188] The processor 21 is configured to implement the steps of the transaction processing method for a multi-core processor as described in the above embodiments when executing a computer program.

[0189] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array. The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0190] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the transaction processing method of the multi-core processor disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary storage or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the transaction processing method of the multi-core processor mentioned above.

[0191] In some embodiments, the electronic device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0192] Those skilled in the art will understand that Figure 5 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0193] The electronic device provided in this embodiment of the invention includes a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a transaction processing method for a multi-core processor, with the same effect as above.

[0194] This invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the transaction processing method for a multi-core processor described above.

[0195] Finally, the present invention also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, performs the steps described in the above method embodiments.

[0196] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0197] The computer-readable storage medium provided by this invention includes the transaction processing method for multi-core processors mentioned above, and has the same effect.

[0198] The present invention has provided a detailed description of a transaction processing method for a multi-core processor, a multi-core processor, and an electronic device. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to the present invention without departing from the principles of the invention, and these improvements and modifications also fall within the protection scope of the present invention.

[0199] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A transaction processing method for a multi-core processor, characterized in that, Applied to the source end, including: Acquire the target transaction on a multi-core processor; If the target transaction is a read / write transaction for multiple consecutive cache line addresses, then obtain the read / write transaction identifier and the read / write transaction address; configure the opcode of the target protocol as the read / write transaction identifier, and configure the address field of the target protocol as the read / write transaction address to generate a merged data packet; wherein, the opcode includes a reserved field; If the target transaction is multiple failure listener request transactions, the destination node identifiers of the multiple failure listener request transactions are merged in the target protocol to generate a merged data packet; wherein, the target protocol is a cache consistency protocol; The merged data packet is sent to the destination; wherein the source and destination are determined based on the transaction type; Configuring the address field of the target protocol as the read / write transaction address includes: Configure the address field of the target protocol as the starting address of the consecutive cache line addresses; The source node is the master node; in the target protocol, the destination node identifiers of multiple failed listening request transactions are merged to generate a merged data packet, including: In the destination node identifier field of the target protocol, the destination node identifiers of multiple failed listening request transactions are merged. In the flag field of the target protocol, an identifier representing the merged or non-merged listening request is configured. In the quantity field of the target protocol, the number of merged failed listening request transactions is configured to generate a merged listening request data packet. Sending the merged data packet to the destination includes: The merged listening request data packet is sent to the destination.

2. The transaction processing method for a multi-core processor according to claim 1, characterized in that, Obtaining the read / write transaction identifier includes: Obtain the first mapping relationship between the pre-established read / write transaction identifier and the read / write transaction; wherein, the read / write transaction identifier is composed of information from the reserved field in the opcode and information from the remaining field in the opcode; The read / write transaction identifier corresponding to the target transaction is determined based on the first mapping relationship.

3. The transaction processing method for a multi-core processor according to claim 1, characterized in that, The target transaction is a read transaction in a read-write transaction that targets multiple consecutive cache line addresses; the source is the target request node; and the destination is the master node. After sending the merged data packet to the destination, the process also includes: In the master node, the merged data packet is split into multiple read request data packets based on the opcode field and address field in the merged data packet; the directory is queried based on the multiple read request data packets, and a listening data packet is generated to be sent to the request node to be monitored or a read data packet is sent to the slave node according to the cache line status recorded in the directory; the read request response data packets sent by the request node to be monitored or the slave node are obtained, and the read request response data packets are returned to the target request node in sequence; wherein, the destination address in the multiple read request data packets is obtained by offsetting the address field in the merged data packet.

4. The transaction processing method for a multi-core processor according to claim 3, characterized in that, Before the master node sequentially returns the read request response data packet to the target request node, it also includes: Obtain the second mapping relationship between the pre-established read transaction identifier and the read transaction of the cache line data fragment; wherein, the read transaction identifier is characterized by the information in the reserved field in the opcode; Based on the read transaction of the target cache row data fragment and the second mapping relationship, the opcode in the target read request response data packet is added with the corresponding read transaction identifier to generate the final read request response data packet corresponding to the target cache row data fragment; wherein, the target read request response data packet is the request response data packet corresponding to the target cache row data fragment.

5. The transaction processing method for a multi-core processor according to claim 1, characterized in that, The target transaction is a write transaction within a read-write transaction that targets multiple consecutive cache line addresses; the source is the target request node; and the destination is the master node. After sending the merged data packet to the destination, the process also includes: In the master node, the merged data packet is split into multiple write request data packets according to the opcode field and address field in the merged data packet; and information for receiving write data is sent to the target request node; wherein the destination address in the multiple write request data packets is obtained by offsetting the address field in the merged data packet.

6. The transaction processing method for a multi-core processor according to claim 5, characterized in that, After the master node sends information indicating receipt of write data to the target requesting node, it also includes: Obtain the third mapping relationship between the pre-established write transaction identifier and the write transaction of the cache line data fragment; wherein, the write transaction identifier is characterized by the information in the reserved field in the opcode; Based on the write transaction of the target cache row data fragment and the third mapping relationship, the corresponding write transaction identifier is added to the opcode in the target write request response data packet to generate the final write request response data packet corresponding to the target cache row data fragment; wherein, the target write request response data packet is the request response data packet corresponding to the target cache row data fragment; Each of the final write request response data packets is sent to the master node in sequence.

7. The transaction processing method for a multi-core processor according to claim 1, characterized in that, Before sending the merged listening request data packet to the destination, the process also includes: Obtain the pre-defined routing method for the merged listening request data packets; The destination to which the merged listening request data packet is to be sent is determined based on the routing method.

8. The transaction processing method for a multi-core processor according to claim 7, characterized in that, The destination to which the merged listening request data packet is to be sent is determined based on routing methods, including: If the routing method is detected as the master node sending the merged listening request data packet to the listening relay module, and the listening relay module forwarding the listening request data packet to the corresponding destination node, then the destination to which the merged listening request data packet is to be sent is determined to be the listening relay module.

9. The transaction processing method for a multi-core processor according to claim 8, characterized in that, After sending the merged listening request data packet to the destination, the process also includes: Parse the merged listening request data packet and obtain the parsing result; If the flag field in the parsing result is configured to represent the merged listening request, then a corresponding number of listening request data packets are generated according to the number of merged failed listening request transactions configured in the quantity field; wherein, the destination node identifier field in each listening request data packet corresponds to the identifier field of a destination node in the merged listening request data packet. The listening request data packets are sent to the corresponding destination node through the listening relay module.

10. The transaction processing method for a multi-core processor according to claim 9, characterized in that, After the listening request data packets are sent to the corresponding destination node by the listening relay module, the method further includes: The monitoring relay module receives monitoring response data packets sent by each destination node; in the destination node identifier field of the target protocol, the node identifiers corresponding to the destination nodes of multiple monitoring responses are merged; in the flag field of the target protocol, an identifier representing the merged monitoring response or the non-merged monitoring response is configured; in the quantity field of the target protocol, the number of merged monitoring responses is configured to generate a merged monitoring response data packet; and the merged monitoring response data packet is sent to the master node.

11. The transaction processing method for a multi-core processor according to claim 7, characterized in that, The destination to which the merged listening request data packet is to be sent is determined based on routing methods, including: If the routing method is detected to be that the master node sends the merged listening request data packet to a preset destination node among all destination nodes, and performs the next level transmission according to the destination node in the merged listening request data packet, then the destination is determined to be the preset destination node.

12. The transaction processing method for a multi-core processor according to claim 11, characterized in that, Sending the merged data packet to the destination includes: The merged listening request data packet is sent to the preset destination node; After sending the merged listening request data packet to the preset destination node, the method further includes: In the preset destination node, the merged listening request data packet is parsed, the parsing result is obtained, and the listening information destined for the local node is downloaded from the merged listening request data packet; If the flag field in the parsing result contains a configuration representing the merged listening response, then determine whether the number of merged listening responses minus 1 equals 0. If so, then confirm that the forwarding of the merged listening request data packet has been completed; If not, the value obtained by subtracting 1 from the number of merged listening responses is assigned to the quantity field, and the node identifiers corresponding to each node after the preset destination node in the merged listening request data packet are subtracted by 1 to obtain the information of the new destination node identifier field, so as to generate the new merged listening request data packet. The steps include transmitting the new merged listening request data packet to the destination node corresponding to the first destination node identifier in the information of the new destination node identifier field, returning the parsing of the merged listening request data packet and obtaining the parsing result, and downloading the listening information to be sent to the local node from the merged listening request data packet.

13. The transaction processing method for a multi-core processor according to claim 11 or 12, characterized in that, In the destination node identifier field of the target protocol, merging the destination node identifiers of multiple failed listener request transactions includes: In the destination node identifier field of the target protocol, the node identifiers corresponding to the destination nodes of multiple listening responses are sorted sequentially according to the routing order.

14. The transaction processing method for a multi-core processor according to claim 13, characterized in that, Also includes: After the destination node obtains the corresponding listening request data packet, it sequentially receives the listening response data packets sent by each destination node.

15. A multi-core processor, characterized in that, Including the source and destination ends; The source end is used to obtain the target transaction on the multi-core processor; if the target transaction is a read / write transaction for multiple consecutive cache line addresses, then the read / write transaction identifier and read / write transaction address are obtained; The target protocol's opcode is configured as the read / write transaction identifier, and the target protocol's address field is configured as the read / write transaction address to generate a merged data packet; wherein the opcode includes a reserved field; if the target transaction is multiple failure listening request transactions, the destination node identifiers of the multiple failure listening request transactions are merged in the target protocol to generate a merged data packet; wherein the target protocol is a cache consistency protocol; the merged data packet is sent to the destination; wherein the source and destination are determined based on the transaction type; The destination end is used to receive the merged data packet sent by the source end; Configuring the address field of the target protocol as the read / write transaction address includes: Configure the address field of the target protocol as the starting address of the consecutive cache line addresses; The source node is the master node; in the target protocol, the destination node identifiers of multiple failed listening request transactions are merged to generate a merged data packet, including: In the destination node identifier field of the target protocol, the destination node identifiers of multiple failed listening request transactions are merged. In the flag field of the target protocol, an identifier representing the merged or non-merged listening request is configured. In the quantity field of the target protocol, the number of merged failed listening request transactions is configured to generate a merged listening request data packet. Sending the merged data packet to the destination includes: The merged listening request data packet is sent to the destination.

16. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the transaction processing method of the multi-core processor according to any one of claims 1 to 14.

17. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the transaction processing method of a multi-core processor as described in any one of claims 1 to 14 when executing the computer program.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the transaction processing method for a multi-core processor as described in any one of claims 1 to 14.

Images