A method for handling cache consistency between DIEs and a data sharing acceleration device

Abstract

This application proposes a method for handling cache consistency between DIEs and a data sharing acceleration device. It includes constructing an interconnected architecture of multiple CPU DIEs and multiple IO DIEs, combined with a state hierarchical state management mechanism, overcoming the limitation of strong coupling between state records and the number of DIEs in traditional architectures. When performing cache consistency maintenance on three-layer state data, the target CPU DIE calls its local first and second states, reducing the number of interactions and data transfer volumes for cross-DIE consistency requests. The third state only records cache state changes, not the full state. Compared to existing solutions that require storing the full state, this accelerates the synchronization of dirty data in the cache to memory, significantly reduces the overall transmission latency of data interaction between DIEs, reduces the capacity requirement of the state recorder for cache consistency maintenance, lowers hardware design complexity and manufacturing costs, and reduces system overhead caused by invalid consistency requests.

Description

Technical Field

[0001] This application relates to the field of chip design technology, and in particular to a method for handling cache coherency between DIEs and a data sharing acceleration device. Background Technology

[0002] In multi-DIE (i.e., bare die or bare chip, which is a small piece of integrated circuit made of semiconductor material without packaging) interconnect architecture, as the number of DIEs increases, cross-DIE cache coherency maintenance faces many technical bottlenecks: IO DIEs (i.e., input / output dies) need to record cache coherency maintenance tasks between all CPU DIEs (i.e., central processing unit dies), resulting in high capacity requirements and resource consumption of the IODIE-side state logger, leading to high hardware deployment and operation costs; at the same time, the transmission latency of data interaction between DIEs is high, and the efficiency of synchronizing dirty data in the cache to memory is low, which restricts the data sharing speed under multi-DIE interconnect architecture. Summary of the Invention

[0003] The purpose of this application is to at least partially solve one of the technical problems in the related art.

[0004] Therefore, the first objective of this application is to propose a method for handling cache consistency between DIEs.

[0005] The second objective of this application is to propose a data sharing acceleration device.

[0006] The third objective of this application is to propose an electronic device.

[0007] The fourth objective of this application is to provide a computer-readable storage medium.

[0008] The fifth objective of this application is to provide a computer program product.

[0009] To achieve the above objectives, a first aspect of this application proposes a method for inter-DIE cache consistency processing, comprising:

[0010] Establish an interconnect architecture comprising multiple CPU DIEs, routing DIEs, and multiple IO DIEs, wherein each CPU DIE integrates multiple CPU cores;

[0011] The system acquires the first and second states within each CPU DIE and the third state of each IO DIE in real time. The first state is used to record the cache line state of a single CPU core, the second state is used to record the cache line state between different DIEs, and the third state is used to record the cache state changes of all CPU DIEs.

[0012] In response to at least one CPU core within any CPU DIE initiating a cache access request, cache consistency maintenance is performed based on the first state, the second state, and the third state, wherein the CPU DIE that initiated the cache access request is taken as the target CPU DIE.

[0013] To achieve the above objectives, a second aspect of this application provides a data sharing acceleration device, comprising:

[0014] An interconnect module is used to establish an interconnect architecture that includes multiple CPU DIEs and multiple IO DIEs, wherein each CPU DIE integrates multiple CPU cores;

[0015] The status recording module is used to acquire the first and second states within each CPU DIE and the third state of each IO DIE in real time. The first state is used to record the cache line state of a single CPU core, the second state is used to record the cache line state between different DIEs, and the third state is used to record the cache state changes of all CPU DIEs.

[0016] The request processing module is configured to respond to a cache access request initiated by at least one CPU core within any CPU DIE, and to perform cache consistency maintenance based on the first state, the second state, and the third state, wherein the CPU DIE that initiated the cache access request is designated as the target CPU DIE.

[0017] To achieve the above objectives, a third aspect of this application provides an electronic device, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the steps of the DIE inter-cache coherence processing method proposed in the first aspect of this application.

[0018] To achieve the above objectives, a fourth aspect of this application provides a computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the steps of the DIE inter-cache coherence processing method proposed in the first aspect of this application.

[0019] To achieve the above objectives, a fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor in a communication device, implements the steps of the DIE inter-cache coherence processing method proposed in the first aspect of this application.

[0020] In this embodiment, by constructing an interconnected architecture of multiple CPU DIEs and multiple IO DIEs, and combining a hierarchical state management mechanism of first state-second state-third state, the limitation of strong coupling between state records and the number of DIEs in traditional architectures is overcome. This allows for flexible configuration of multi-DIE expansion needs of different scales, providing a feasible architectural reference for building ultra-large-scale multi-DIE systems. When performing cache consistency maintenance based on three-layer state data, the target CPU DIE can call its local first and second states, reducing the number of interactions and data transfer volumes for cross-DIE consistency requests. The third state of the IO DIE only records cache state changes, not the full state. Compared to existing technologies where IO DIEs need to store the full state, this accelerates the synchronization of dirty data in the cache to memory, significantly reduces the overall transmission latency of data interaction between DIEs, greatly reduces the capacity requirement of state recorders for cache consistency maintenance on IO DIEs, lowers the hardware design complexity and manufacturing cost of IO DIEs, and reduces the system functional overhead caused by invalid consistency requests.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0023] Figure 1 A flowchart illustrating a method for handling inter-DIE cache consistency provided in an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of an interconnection architecture provided according to an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of a board-level DIE layout provided according to an embodiment of this application;

[0026] Figure 4 This is a schematic diagram of a CPU DIE status recorder format provided according to an embodiment of this application;

[0027] Figure 5 This is a schematic diagram of an IO DIE state recorder format provided according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of the structure of a data sharing acceleration device provided in an embodiment of this application;

[0029] Figure 7This is a schematic diagram of the structure of an electronic device according to an embodiment of this application;

[0030] Figure 8 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0032] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this application. The singular forms “a” and “the” as used in the embodiments of this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0033] It should be understood that although the terms first, second, third, etc., may be used to describe various information in the embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words "if" and "suppose" as used herein can be interpreted as "when," "when," or "in response to a determination."

[0034] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0035] As semiconductor integrated circuits evolve towards higher density and higher performance, multi-DIE (die or bare chip, a small piece of integrated circuit made of semiconductor material without packaging) interconnect architecture has become a core architectural solution for building ultra-large-scale multi-core processors and high-performance computing chips because it can overcome the physical limitations of single-DIE integration scale and flexibly combine different functional modules (such as computing modules, storage modules, and input / output modules). In this architecture, cross-DIE cache coherency maintenance is a key link to ensure the collaborative work of multiple CPU dies and accurate and reliable data access. However, with the continuous increase in the number of CPU dies and I / O dies in the architecture, this link has gradually exposed many technical bottlenecks, which seriously restrict the performance improvement and cost optimization of the architecture.

[0036] In some scenarios, the hardware resource overhead of IO DIEs surges. In the design logic of existing multi-DIE interconnect architectures, IO DIEs are tasked with the centralized maintenance of cache consistency across multiple CPU DIEs, requiring them to comprehensively manage cache consistency across all CPU DIEs. This necessitates that IO DIEs accurately track the detailed status of each cache line within each CPU DIE, including core attributes such as valid, invalid, shared, exclusive, and modified. Simultaneously, they must respond in real-time to various cross-DIE consistency requests (such as cache line read, write, and invalidation requests) and coordinate the access order of shared data across multiple CPU DIEs to avoid conflicts. As the number of CPU DIEs increases, the corresponding number of CPU cores and cache lines grow linearly or even exponentially, placing extremely high storage capacity demands on the IO DIE-side state recorders (such as consistency status registers and cache tag storage units) to ensure the complete and accurate recording of cache status information corresponding to all CPU cores. However, this tightly coupled design pattern has brought a series of problems: it not only leads to a significant increase in the chip area ratio of IO DIE and a significant increase in the complexity and difficulty of hardware design and R&D, but also directly increases the chip tape-out cost and the difficulty of mass production yield control; at the same time, the continuous operation of the high-capacity state recorder will generate a lot of static power consumption, further aggravating the chip's operating energy consumption cost.

[0037] In some scenarios, the data transmission latency between DIEs remains high, severely limiting data sharing efficiency. Maintaining cross-DIE cache consistency essentially relies on the transmission and interaction of numerous consistency request and response packets between DIEs. However, as the number of DIEs increases, the transmission path of data packets lengthens, and the number of forwards increases, leading to increased transmission time. It's worth noting that existing architectures lack efficient state layering management mechanisms; most consistency requests need to be transmitted across multiple CPU DIEs to the IO DIE for centralized judgment and processing, further amplifying the transmission latency problem.

[0038] In some scenarios, the inefficiency of synchronizing dirty data (data copies modified by the CPU core but not yet synchronized back to main memory) from the cache to main memory is particularly pronounced. The synchronization of dirty data must strictly follow the complete process of "IO DIE status verification → synchronization request initiation → cross-DIE data transfer → main memory writing." Excessive transmission latency can cause dirty data to remain in the local cache for extended periods. This can not only lead to access conflicts between multiple CPU DIEs for the same shared data, causing data read errors or abnormal calculation results, but also reduce the freshness of main memory data, making it difficult for subsequent access requests from other CPU DIEs to obtain the latest data. Ultimately, this inefficient data synchronization model severely restricts the speed of shared data access between multiple DIEs, failing to fully unleash the performance potential of parallel computing by multiple CPU DIEs.

[0039] In summary, given the surging demand for chip computing power in fields such as high-performance computing and artificial intelligence, existing cross-DIE cache consistency maintenance methods can no longer meet the needs of industrial development. Therefore, it is urgent to propose a new technical solution to overcome the above limitations and achieve performance optimization and cost control of multi-DIE interconnect architecture.

[0040] The following describes, with reference to the accompanying drawings, a method for handling DIE cache consistency and a data sharing acceleration device according to embodiments of this application.

[0041] Figure 1 This is a flowchart illustrating a method for handling inter-DIE cache consistency provided in an embodiment of this application.

[0042] like Figure 1 As shown, the inter-DIE cache consistency handling method includes, but is not limited to, the following steps:

[0043] S101 establishes an interconnect architecture that includes multiple CPU DIEs, routing DIEs, and multiple IO DIEs, where each CPU DIE integrates multiple CPU cores.

[0044] In one feasible implementation, the interconnect architecture uses multiple CPU dies (Central Processing Unit dies) as core computing units. Each CPU die integrates multiple CPU cores, and the number of CPU cores can be flexibly configured according to the computing task requirements (e.g., 8 cores, 16 cores, 32 cores, etc.). Each CPU core is equipped with a private cache (L1 cache / L2 cache), while all CPU cores within the same CPU die share a single level cache (L3 cache), enabling parallel computing capabilities and the ability to process multiple tasks simultaneously.

[0045] In one feasible implementation, each CPU die incorporates an on-chip communication architecture, which can be an interconnect or an on-chip network (NOC), to enable high-speed data exchange between CPU cores within the same CPU die and to maintain on-chip cache consistency. It should be noted that the communication architecture manages data synchronization between private and shared caches through consistency protocols such as MESI and MOESI.

[0046] In one feasible implementation, multiple IO dies (input / output dies) act as bridges between the interconnect architecture and external devices, undertaking the task of maintaining cross-die cache consistency. The number of IO dies is flexibly configured based on external device access requirements and cross-die consistency maintenance pressure. Each IO die has a built-in cross-die communication architecture, which is either an input / output interconnect link (Interconnect_io) or an input / output on-chip network (NOC_io). In some scenarios, each IO die also integrates multiple external device interfaces, such as storage interfaces, network interfaces, and peripheral interfaces. Each IO die handles read / write access requests between external devices (such as memory, hard drives, network cards, graphics cards, etc.) and the CPU die, enabling data transfer between the interconnect architecture and external devices. It should be noted that multiple IO dies are deployed in a distributed manner, which can distribute the consistency maintenance pressure and reduce the resource overhead of a single IO die.

[0047] In one feasible implementation, if the number of CPU DIEs and IO DIEs is small (for example, the number of CPU DIEs < 3 and the number of IO DIEs < 2), a Router DIE (router die) may not be set up; if the number of CPU DIEs and IO DIEs exceeds a preset threshold, a Router DIE is set up within the interconnect architecture. The Router DIE is used for data relay and forwarding between each CPU DIE and each IO DIE; alternatively, the Router DIE can be integrated inside the IO DIE.

[0048] In some embodiments, the Router DIE serves as the data transmission hub of the interconnect architecture, ensuring the efficiency and reliability of communication between multiple DIEs. The Router DIE integrates a high-performance routing and switching module, multiple inter-DIE communication interfaces, and a data buffer unit, supporting various high-speed interconnect protocols such as PCIe 5.0 / 6.0, HBM, and UCIe. The Router DIE receives data packets from each CPU DIE and each IO DIE, determines the optimal transmission path using built-in routing algorithms (such as shortest path algorithms and load balancing algorithms), and forwards data packets between different DIEs. Simultaneously, the Router DIE performs verification, error correction, and flow control on data packets during transmission to prevent data loss or transmission congestion.

[0049] In some embodiments, Figure 2 This is a schematic diagram of an interconnection architecture provided according to an embodiment of this application. Figure 2 As shown, the interconnect architecture includes 3 CPU DIEs, a Router DIE, and 2 IO DIEs. Each CPU DIE includes multiple CPU cores (8 CPU cores for example), an Interconnect or on-chip Networking Object (NOC) link, and a DIE port; each IO DIE includes multiple Device devices (4 Device devices for example), an I / O Interconnect or I / O NOC link, a DIE port, and Memory.

[0050] In some embodiments, Figure 3 This is a schematic diagram of a board-level DIE layout according to an embodiment of this application. Figure 3 As shown, in the field of chip design, such as multi-core processors, system-on-a-chip, or heterogeneous integrated chips, BLOCK0 and BLOCK1 represent different functional units or sub-modules within the chip.

[0051] For example, BLOCK0 is a functional unit or submodule responsible for specific computing tasks, such as digital signal processing, AI acceleration, and graphics processing; BLOCK1 is a functional unit or submodule responsible for memory control, bus interface, and power management. BLOCK0 includes CPU DIE0, CPU DIE1, CPU DIE2, and CPU DIE3; BLOCK1 includes CPU DIE4, CPU DIE5, CPU DIE6, and CPU DIE7. Data interaction shows that CPU DIE0 and CPU DIE4 have the shortest transmission distance to IO DIE0, while CPU DIE3 and CPU DIE7 have the longest transmission distance to IO DIE0.

[0052] S102 acquires the first and second states within each CPU DIE and the third state of each IO DIE in real time. The first state is used to record the cache line state of a single CPU core, the second state is used to record the cache line state between different DIEs, and the third state is used to record the cache state changes of all CPU DIEs.

[0053] In one feasible implementation, Figure 4 This is a schematic diagram of a CPU DIE status recorder format provided according to an embodiment of this application. Figure 4 As shown, assuming the CPU DIE includes 8 CPU cores, in the CPU DIE state recorder format, position L4 is the position closest to the DIE port, positions L3 and L5 are relatively close to the DIE port, and positions L0 and L8 are relatively far from the DIE port, with the interaction distance between positions L0 and L8 being the longest.

[0054] In some embodiments, such as Figure 1 and Figure 4 As shown, in CPU DIE0, the snoop filter inside the Interconnect0 maintains the cache coherency state from CPU0 core to CPU7 core. In addition to recording the state of the cache lines corresponding to the eight CPU cores, the snoop filter also records the state values ​​of the cache lines between DIEs.

[0055] In some embodiments, such as Figure 4 As shown, the DIE state is the second state, responsible for recording the state of cache lines across different DIEs. Only consistency maintenance requests between DIEs can change the DIE state value. The CPU0 state to CPU7 state are the first states, responsible for recording the state of the cache lines corresponding to each CPU core within the CPU DIE. This state value is modified by consistency maintenance requests from the CPU DIE.

[0056] In some embodiments, such as Figure 4 As shown, the rules that the interconnect links within a CPU DIE must follow to maintain cache line consistency include: first, identifying whether the DIE state is valid; if the DIE state does not meet the permissions of the current state for the operation to be performed by a certain CPU core, then the CPU DIE needs to send a consistency maintenance request and obtain the corresponding cache line permissions from the DIE before the CPU core within that CPU DIE can perform subsequent shared operations.

[0057] In some embodiments, the CPU DIE acquires operating privileges through the MOESI protocol. The MOESI protocol further optimizes data sharing and consistency among multiple DIEs by introducing the Owned state. The five states of the MOESI protocol are Modified, Exclusive, Shared, Invalid, and Owned, and their meanings are as follows:

[0058]

[0059] In some embodiments, the first state (CPU state) and the second state (DIEstate) within each CPU DIE satisfy the following correspondence:

[0060] Taking CPU DIE0 as an example, such as Figure 4 As shown, if the CPU DIE's DIE state is Invalid, then CPU0 state to CPU7 state are all Invalid, and this state is represented as S000.

[0061] like Figure 4 As shown, if the DIE state of the CPU DIE is Exclusive, only one CPU state from CPU0 to CPU7 is Exclusive, and the other CPU states are Invalid. This state is represented as S001.

[0062] like Figure 4 As shown, if the DIE state of the CPU DIE is Exclusive, only one CPU state from CPU0 to CPU7 has Modified, and the other CPU states are Invalid. This state is represented as S002.

[0063] like Figure 4 As shown, if the DIE state of the CPU DIE is Exclusive, one of the CPU states from CPU0 to CPU7 must be Shared, and the other CPU states are a random combination of Shared and Invalid. This state is represented as S003.

[0064] like Figure 4As shown, if the DIE state of the CPU DIE is Exclusive, only one CPU state from CPU0 to CPU7 is Owned, and the other CPU states are a random combination of Shared and Invalid, this state is represented as S004.

[0065] like Figure 4 As shown, if the DIE state of the CPU DIE is Modified, only one CPU state from CPU0 to CPU7 is Modified, and the other CPU states are Invalid. This state is represented as S005.

[0066] like Figure 4 As shown, if the DIE state of the CPU DIE is Modified, only one CPU state from CPU0 to CPU7 is Owned, and the other CPU states are a random combination of Shared and Invalid. This state is represented as S006.

[0067] like Figure 4 As shown, if the DIE state of the CPU DIE is Shared, then one of the CPU states from CPU0 to CPU7 must be Shared, and the other CPU states are a random combination of Shared and Invalid. This state is represented as S007.

[0068] like Figure 4 As shown, if the CPU DIE's DIE state is Owned, only one CPU state from CPU0 to CPU7 is Owned, and the other CPU states are a random combination of Shared and Invalid. This state is represented as S008.

[0069] It's important to note that the DIE state (i.e., the second state) only records the interaction status values ​​of cache lines between DIEs and does not serve as a status identifier for cache lines of individual CPU cores within the CPU DIE. The DIE state value cannot be changed when CPU cores within the CPU DIE are sharing data. Modifications to the DIE state value typically need to be synchronized to the IO DIE. When the DIE state is valid (valid states include Exclusive, Modified, Shared, and Owned), multiple CPU states (i.e., the first states) within the CPU DIE must also have valid states.

[0070] In one feasible implementation, the third state of the IO DIE is used to record cache line state changes for all CPU DIEs, including the cache line state change event type, the CPU-specific identifier involved in the change, and the specific motivation that triggered the cache line state change.

[0071] In some embodiments, the cache line state change event type refers to the specific type of cache line state change. Since the first state (CPU state) records the cache line state of a single CPU core, a corresponding cache line state change event type is generated when the first state changes.

[0072] In some embodiments, the CPU-specific identifier involved in the change is used to identify the CPU DIE that has undergone the change. Since the first state (CPU state) records the cache line state of a single CPU core, and the second state (DIE state) records the cache line state across different DIEs, the second state clearly defines the interaction range within the CPU DIE to which the CPU core belongs. Combining the first and second states allows the identification of the CPU DIE that has undergone the change, thereby generating a unique identifier for the CPU DIE that has undergone the change and avoiding identity confusion in multi-DIE scenarios.

[0073] In some embodiments, the specific cause triggering a cache line state change is directly related to the first state (CPU state) and the second state (DIE state). If the specific cause is a "core access request," which originates from a CPU core's read / write operation on its local cache, this read / write operation corresponds to a first state change; or if the "core access request" originates from shared data access between multiple DIEs, this shared data access between multiple DIEs corresponds to a second state change. If the specific cause is an "external device request," which originates from an access request initiated by an external device through an IO DIE, it will indirectly trigger a cache line state change within the CPU DIE (including both first and second state changes).

[0074] In one feasible implementation, the third state of the IO DIE records the cache state changes of all CPU DIEs, and also includes: dividing each CPU DIE into different distance levels based on the transmission distance between each CPU DIE and the IO DIE in the board-level DIE layout; and storing the cache state of the corresponding CPU DIE in order of distance level, so that each CPU DIE is retrieved from near to far according to the transmission distance to the IO DIE. It should be noted that the third state does not need to record the specific cache line state of all CPU cores. By combining distance level division and effective storage, the storage pressure on IO DIE state can be reduced while improving cache state retrieval efficiency, further optimizing the latency of data interaction across DIEs.

[0075] In one feasible implementation, CPU states within a CPU DIE cannot be directly used between DIEs. When an IODIE initiates a Snoop data forwarding request to a CPU DIE, the state relationships of the IODIEs are as follows:

[0076] If the CPU DIE execution state is S000, then the IO DIE's status for obtaining the corresponding cache line is Invalid.

[0077] If the CPU DIE is in execution state S001, then the IO DIE is in the Exclusive state when acquiring the corresponding cache line.

[0078] If the CPU DIE is in state S002, then the IO DIE will obtain the corresponding cache line in state Modified. It should be noted that the Modified state is the dirty data modification performed by the CPU core after obtaining exclusive access, which can be completed without notifying the IO DIE.

[0079] If the CPU DIE is in execution state S003, the IO DIE obtains the corresponding cache line in Exclusive state; while the CPU core in Owned state has shared data and can complete the process without notifying the IO DIE, and the CPU DIE still has the right to modify the data.

[0080] If the CPU DIE is in execution state S004, then the IO DIE obtains the corresponding cache line with the state "Modified". Specifically, the CPU DIE's second state (DIE state) first obtains the "Exclusive" state. Then, a CPU core within the CPU DIE modifies its first state (CPU state) to "Modified". Finally, the CPU cores within the CPU DIE share and switch the first state (CPU state) to "Owned". For caches between DIEs, cache lines are recognized as "Modified" across DIEs, so the cache line state obtained by the IO DIE is "Modified".

[0081] If the CPU DIE is in execution state S005, then the IO DIE will obtain the corresponding cache line in a modified state.

[0082] If the CPU DIE is in state S006, then the IO DIE obtains the corresponding cache line in a Modified state. After the CPU cores within the CPU DIE are shared, the Modified state switches to the Owned state. For caches between DIEs, it can still be considered to be in a Modified state, and the CPU DIE still has the right to modify data.

[0083] If the CPU DIE is in execution state S007, then the IO DIE is in the Shared state when it obtains the corresponding cache line.

[0084] If the CPU DIE is in execution state S008, then the IO DIE is in the Owned state when acquiring the corresponding cache line.

[0085] In some embodiments, in a multi-DIE interconnect architecture, when a CPU DIE needs to be replaced due to fault, upgrade, or load scheduling (i.e., the original CPU DIE is removed and a new CPU DIE is connected), the CPU core holding dirty data (not the IO DIE or other components) is responsible for writing the unsynchronized dirty data in its own cache back to main memory or shared storage medium, and then performing the CPU DIE replacement operation after completing the data.

[0086] For example, the CPU core holding dirty data is confirmed through the first state (CPU state), and the state of the initiating core is modified in conjunction with the second state (DIE state), thereby avoiding the loss of dirty data during the CPU DIE replacement process, and without relying on the IO DIE to perform centralized write-back.

[0087] It should be added that the cache coherency state of CPU DIE0 to CPU DIE7 is maintained by the listener filter inside the Interconnect_io input / output interconnect link. The state logger of the IO DIE uses a fixed storage format to store the state of each CPU DIE. When the state logger is read, the position information can be obtained, and subsequent Snoop data forwarding listener requests can be sent based on the corresponding position information to share data.

[0088] In one feasible implementation, Figure 5 This is a schematic diagram of an IO DIE state recorder format provided according to an embodiment of this application. It should be noted that, according to... Figure 3 The layout of each DIE in the mid-plate stage, according to Figure 5 The data is stored in the specified format.

[0089] In some embodiments, such as Figure 5 As shown, the distance between positions P0 and P7 is the farthest, while the distance between positions P3 and P4 is the shortest. Furthermore, positions P3 and P4 are closest to the IO die. Then, the corresponding CPU die state is filled into the state logger format, where the CPU die 0 state includes the CPU die 7 state.

[0090] S103, responding to at least one CPU core in any CPU DIE initiating a cache access request, and performing cache consistency maintenance based on the first state, the second state, and the third state, wherein the CPU DIE that initiated the cache access request is taken as the target CPU DIE.

[0091] In one feasible implementation, in response to a cache access request being an exclusive read request, the IO DIE queries its own state logger; if its own state logger indicates that the cache state of all CPU DIEs is Invalid, the IO DIE reads the memory data and feeds the memory data back to the CPU DIE; after completing the reading of the memory data and feeding the memory data back to the CPU DIE, the IO DIE sets the second state of the target CPU DIE to Exclusive and the first state of the CPU core in the target CPU DIE that initiated the consistent exclusive read request to Exclusive.

[0092] Exemplary illustration, such as Figure 3 As shown, the CPU core in CPU DIE1 initiates a consistent exclusive read request. CPU DIE1 sends the consistent exclusive read request to IO DIE0; the listening filter in IO DIE0 finds that all CPU DIEs are currently in an invalid state, so it reads the memory data and returns it to CPU DIE1. After the operation is completed, the IO DIE state logger records that CPU DIE1's state is Exclusive, while the other CPU DIE states remain Invalid; the CPU DIE1 state logger shows the DIE state (i.e., the second state) as Exclusive, while the CPU state of the CPU core that initiated the consistent exclusive read request (i.e., the first state) is Exclusive, and the CPU state of the other CPU cores remains Invalid.

[0093] It should be added that the CPU core that initiates the consistent exclusive read request in CPU DIE1 has the right to rewrite the data; other CPU cores can switch between states S001, S002, S003, and S004 without sending a consistency request to notify IO DIE0.

[0094] In one feasible implementation, in response to a cache access request being a consistent shared read request, the IO DIE queries its own state logger and selects CPU DIEs with valid states as initial source CPU DIEs. These valid states include Exclusive, Modified, Shared, and Owned. Based on the transmission distance between the multiple initial source CPU DIEs and the IO DIE, and considering the block to which the target CPU DIE belongs, the IO DIE sends a Snoop data forwarding listening request to the initial source CPU DIE that meets the requirements to perform cache consistency maintenance.

[0095] In some embodiments, by quantifying the transmission distances of multiple initial source CPU DIEs and considering the sensitivity of the block to which the target CPU DIE initiating the cache access request belongs to transmission latency, a preset priority rule is used to determine the comprehensive score of the multiple initial source CPU DIEs. The initial source CPU DIE with the highest comprehensive score is selected as the candidate source CPU DIE, and the IO DIE sends a Snoop data forwarding listening request to the candidate source CPU DIE to perform cache consistency maintenance. It should be noted that the preset priority rule satisfies one of the following conditions: data to be shared and read is preferentially obtained from CPU DIEs in a valid state within the block to which the target CPU DIE belongs; if all CPU DIEs in the block to which the target CPU DIE belongs are invalid, the CPU DIE in another block with the shortest transmission distance and a valid state is selected as the initial source CPU DIE based on the IODIE's own state recorder.

[0096] Specifically, the candidate source CPU DIE transfers the data to be shared to the target CPU DIE; if the second state of the candidate source CPU DIE is Exclusive and the first state of multiple CPU cores is Owned, the second state of the candidate source CPU DIE is updated to Owned, and the second state of the target CPU DIE is updated to Shared; if the second state of the candidate source CPU DIE is Exclusive and the first state of only a single CPU core is valid, the second state of both the candidate source CPU DIE and the target CPU DIE is updated to Shared; if the second state of the candidate source CPU DIE is Modified, the second state of the candidate source CPU DIE is updated to Owned, and the second state of the target CPU DIE is updated to Shared.

[0097] In some embodiments, such as Figure 3As shown, after the CPU core in CPU DIE1 initiates a consistent exclusive read request, the CPU core in CPU DIE3 initiates a consistent shared read request. CPU DIE3 sends the consistent shared read request to IODIE0. The snooping filter in IODIE0 detects the Exclusive state of the DIE state (i.e., the second state) in the state recorder of CPU DIE1, and IODIE0 sends a Snoop data forwarding snooping request to CPU DIE1. CPU DIE1 processes this Snoop data forwarding snooping request. If multiple CPU cores in CPU DIE1 have already shared data, it identifies the target location where the data needs to be forwarded (i.e., the CPU core in CPU DIE3 that initiated the consistent shared read request), and then identifies the transmission distance between the target location and the CPU cores sharing the data within the chip through the Interconnect link or the on-chip network NOC. Within CPU DIE1, it selects the CPU core with the shortest transmission distance (or the smallest transmission delay) as the node for subsequent processing of snooping requests, that is, it only sends Snoop data forwarding snooping requests to this CPU core.

[0098] For example, if CPU DIE1 is in state S004, and CPU DIE3 is farther from IO DIE0 than CPU DIE1 is from IO DIE0, then dirty data remains in CPU DIE1, and this consistent shared read operation does not involve dirty data transfer. In CPU DIE1, the CPU core with the Owned state is selected to acquire the data, and CPU DIE1 modifies its second state (DIE state) value. Then, the data is transferred to CPU DIE3 via the Router DIE, and the returned state response is transmitted to IO DIE0, thus completing the consistent shared read request of CPU DIE3.

[0099] It should be added that after the consistent shared read operation is completed, the CPU DIE1 state in the IO DIE0 state recorder is Owned, and the CPU DIE3 state is Shared; the second state (DIEstate) in the CPU DIE1 state recorder is Owned, and the states of other CPU cores conform to state S008; the second state (DIE state) in the CPU DIE3 state recorder is Shared, and the states of other CPU cores conform to state S007.

[0100] For example, if CPU DIE1 is in execution state S003, CPU DIE1 can select any CPU core with the Shared state to acquire data. After acquiring the data, CPU DIE1 modifies the second state (DIE state) value, and then transmits the data to CPU DIE3 through Router DIE. The returned state response is then transmitted to IO DIE0, thereby completing the consistent shared read request of CPU DIE3.

[0101] It should be added that after the consistent shared read operation is completed, the CPU DIE1 state and the CPU DIE3 state in the IO DIE0 state recorder are in the Shared state; the second state (DIEstate) in the CPU DIE1 state recorder is in the Shared state, and the states of other CPU cores conform to state S007; the second state (DIE state) in the CPU DIE3 state recorder is in the Shared state, and the states of other CPU cores conform to state S007.

[0102] For example, if CPU DIE1 is in state S002, after completing the CPU DIE3 coherent shared read request, the CPU DIE1 state in the IODIE0 state recorder is Owned, and the CPU DIE3 state is Shared; the second state (DIE state) in the CPU DIE1 state recorder is Owned, and the states of other CPU cores conform to state S008; the second state (DIE state) in the CPU DIE3 state recorder is Shared, and the states of other CPU cores conform to state S007.

[0103] For example, if CPU DIE1 is in execution state S001, after completing the CPU DIE3 coherent shared read request, the CPU DIE1 state in the IODIE0 state recorder is Shared, and the CPU DIE3 state is Shared; the second state (DIE state) in the CPU DIE1 state recorder is Shared, and the states of other CPU cores conform to state S007; the second state (DIE state) in the CPU DIE3 state recorder is Shared, and the states of other CPU cores conform to state S007.

[0104] In some embodiments, such as Figure 3As shown, after the CPU core in CPU DIE3 initiates a consistent shared read request, the CPU core in CPU DIE0 initiates a consistent shared read request as well. The listening filter of IO DIE0 detects that CPU DIE3 and CPU DIE1 share the same state within the same BLOCK0. If IO DIE0 records CPU DIE1 as Shared and CPU DIE3 as Owned, IO DIE0 will transfer the Owned state towards the direction closer to IO DIE0, thereby improving the efficiency of subsequent write-backs.

[0105] For example, IO DIE0 initiates a Snoop data forwarding listener request to CPU DIE3. The listener filter in CPU DIE3 forwards the received Snoop data forwarding listener request to the CPU with the Owned state for subsequent processing. After all requests are completed, in the IO DIE0 state logger, CPU DIE0 state is Owned, CPU DIE1 state is Shared, and CPU DIE3 state is Shared; in the CPU DIE0 state logger, the second state (DIEstate) is Owned, and the states of other CPU cores conform to state S008; in the CPU DIE1 state logger, the second state (DIE state) is Shared, and the states of other CPU cores conform to state S007; in the CPU DIE3 state logger, the second state (DIE state) is Shared, and the states of other CPU cores conform to state S007.

[0106] In some embodiments, such as Figure 3As shown, after the CPU core in CPU DIE3 initiates a consistent shared read request, the CPU core in CPU DIE0 initiates a consistent shared read request. The listening filter of IO DIE0 detects that CPU DIE3 and CPU DIE1 share the same state within the same BLOCK0. If IO DIE0 records CPU DIE1 as Owned and CPU DIE3 as Shared, after all requests are completed, the IO DIE0 state logger shows CPU DIE0 as Owned, CPU DIE1 as Shared, and CPU DIE3 as Shared. In the CPU DIE0 state logger, the second state (DIE state) is Owned, and the states of other CPU cores conform to state S008. In the CPU DIE1 state logger, the second state (DIE state) is Shared, and the states of other CPU cores conform to state S007. In the CPU DIE3 state logger, the second state (DIE state) is Shared, and the states of other CPU cores conform to state S007.

[0107] In some embodiments, such as Figure 3As shown, after the CPU core in CPU DIE3 initiates a consistent shared read request, the CPU core in CPU DIE0 initiates a consistent shared read request as well. The listening filter in IO DIE0 detects that CPU DIE3 and CPU DIE1 share a state within the same BLOCK0. If IO DIE0 records both CPU DIE1 and CPU DIE3 as Shared, and IO DIE0 finds no Owned state, it determines the distance based on the position recorded in the IO DIE0 state logger. Since the CPU DIE0 needs to acquire data, and the nearest shared data to CPU DIE0 is in CPU DIE1, IO DIE0 initiates a Snoop data forwarding listening request to CPU DIE1. After all requests are completed, the CPU DIE0 state, CPU DIE1 state, and CPU DIE3 state are all in the Shared state in the IO DIE0 state recorder. The second state (DIE state) in the CPU DIE0 state recorder is in the Shared state, and the states of other CPU cores conform to state S007. The second state (DIE state) in the CPU DIE1 state recorder is in the Shared state, and the states of other CPU cores conform to state S007. The second state (DIE state) in the CPU DIE3 state recorder is in the Shared state, and the states of other CPU cores conform to state S007.

[0108] It should be added that, such as Figure 3 As shown in the above embodiment, the propagation order of the Owned state is from CPU DIE1 to CPU DIE0, with the aim of bringing the Owned state closer to IO DIE0. If the Owned state is located in CPU DIE3, as sharing occurs between DIEs, the Owned state can also be gradually transferred to other CPU DIEs closer to IO DIE0. When a CPU core in the Owned state is replaced and written back, the write-back latency between DIEs can be reduced.

[0109] In one feasible implementation, in response to a cache access request being a consistent write-back operation request, if there are multiple CPU cores in the Shared state in the candidate source CPU DIE, the consistent write-back operation request is transmitted through the IO DIE, and the multiple CPU cores that have completed the cache access request are still kept in the Shared state.

[0110] In response to a cache access request as a consistent write-back operation request, if the candidate source CPU DIE has only one CPU core in the Shared state, the consistent write-back operation request is transmitted through the IO DIE; if the candidate source CPU DIE retains the local data, the second state of the CPU core that completed the cache access request is updated to Exclusive; if the candidate source CPU DIE does not retain the local data, the second state of the CPU core that completed the cache access request is updated to Invalid.

[0111] In response to a cache access request that is a consistent write-back and invalid operation request, if there are multiple CPU cores in the Shared state in the candidate source CPU DIE, the cache access request will be converted into a write-back operation.

[0112] In response to a cache access request that is a consistent write-back and invalid operation request, if the candidate source CPU DIE has only one CPU core in the Shared state, the consistent write-back and invalid operation request is transmitted through the IO DIE, and the CPU core that completed the cache access request is updated from the Shared state to Invalid.

[0113] For example, when a CPU DIE is in execution state S001, if a CPU core in the CPU DIE whose first state (CPU state) is Exclusive initiates a consistency invalidation operation request, then the CPU DIE will pass the invalidation operation request to the IO DIE. After the request is completed, the CPU DIE switches to execution state S000.

[0114] For example, when the CPU DIE is in execution state S002, if a CPU core in the CPU DIE whose first state (CPU state) is Exclusive initiates a consistent write-back and invalidation operation request, then the CPU DIE sends the consistent write-back and invalidation operation request to the IO DIE. After the request is completed, the CPU DIE switches to execution state S000.

[0115] For example, when the CPU DIE is in execution state S002, if a CPU core in the CPU DIE whose first state (CPU state) is Exclusive initiates a consistent write-back operation request, then the CPU DIE sends a consistent write-back and invalidation operation request to the IO DIE. After the request is completed, the CPU DIE switches to execution state S001.

[0116] For example, when the CPU DIE is in state S003, if a CPU core in the CPU DIE with the first state (CPU state) of Shared initiates a consistency invalidation operation request, the state recorder is read to modify the state as follows:

[0117] If the second state (DIE state) within the CPU DIE is Exclusive, and there are multiple CPU cores with the first state (CPU state) being Shared, then the consistency invalidation operation request will be processed within the CPU DIE. The Interconnect or the on-chip network NOC will then define the invalidation operation and modify the corresponding CPU core state (e.g., the first state changes from Shared to Invalid). After the request is completed, the CPU DIE will still be in state S003.

[0118] If the second state (DIE state) within the CPU DIE is Exclusive, there is only one CPU core with the first state (CPU state) Shared. The consistency invalidation operation request is sent to the IO DIE for processing through this CPU core. After the request is completed, the CPU DIE switches to the execution state S000.

[0119] For example, when a CPU DIE is in execution state S004, if its second state is Exclusive and its first state (CPU state) with only one CPU core is Owned, and if the Owned CPU core initiates a consistent write-back operation request, the CPU DIE sends the consistent write-back operation request to the IO DIE for processing. After the request is completed, the CPU DIE enters execution state S000. If the Owned CPU core initiates a consistent write-back and invalid operation request, the CPU DIE sends the consistent write-back and invalid operation request to the IO DIE for processing. After the request is completed, the CPU DIE enters execution state S000.

[0120] For example, when a CPU DIE is in execution state S004, if its second state is Exclusive, and one CPU core's first state is Owned and at least one CPU core's first state is Shared, then if a CPU core in the Shared state initiates a consistency invalidation operation request, the request does not need to be sent to the IO DIE; the CPU DIE handles the request internally, and remains in state S004. If a CPU core in the Owned state initiates a consistency write-back operation request, since its second state is Exclusive, the CPU DIE sends the consistency write-back operation request to the IO DIE for processing. After the request is completed, the CPU DIE switches to execution state S003. If a CPU core in the Owned state initiates a consistent write-back and invalidation operation request, and the state recorder identifies that other CPU cores have a shared copy, then the CPU DIE will convert the consistent write-back and invalidation operation request into a consistent write-back operation request and send the consistent write-back operation request to the IO DIE for processing. After the request is completed, the CPU core in the Owned state switches to the Invalid state, the first state of other CPU cores remains unchanged, and the CPU DIE switches to the execution state S003.

[0121] For example, when the CPU DIE is in execution state S005, if a CPU core in the CPU DIE whose first CPU state is Modified initiates a consistent write-back and invalidation operation request, the CPU DIE sends the consistent write-back and invalidation operation request to the IO DIE for processing. After the request is completed, the CPU DIE switches to execution state S000. If a CPU core in the CPU DIE whose first CPU state is Modified initiates a consistent write-back operation request, after the request is completed, the CPU DIE switches to execution state S001.

[0122] For example, when a CPU DIE is in execution state S006, if its second state is Modified and only one CPU core's first state is Owned, and if the Owned CPU core initiates a consistent write-back operation request, the CPU DIE sends the consistent write-back operation request to the IO DIE for processing. After the request is completed, the CPU DIE enters execution state S003. If the Owned CPU core initiates a consistent write-back and invalidation operation request, the CPU DIE sends the consistent write-back and invalidation operation request to the IO DIE for processing. After the request is completed, the CPU DIE enters execution state S000.

[0123] For example, when a CPU DIE is in execution state S006, if its second state is Modified, one CPU core's first state is Owned, and at least one CPU core's first state is Shared, then if a CPU core in the Shared state initiates a consistency invalidation operation request, the request does not need to be sent to the IO DIE; the CPU DIE handles the request internally, and remains in state S005. If a CPU core in the Owned state initiates a consistency write-back operation request, since its second state is Exclusive, the CPU DIE sends the consistency write-back operation request to the IO DIE for processing. After the request is completed, the CPU DIE switches to execution state S003. If a CPU core in the Owned state initiates a consistent write-back and invalidation operation request, and the state recorder identifies that other CPU cores have a shared copy, then the CPU DIE will convert the consistent write-back and invalidation operation request into a consistent write-back operation request and send the consistent write-back operation request to the IO DIE for processing. After the request is completed, the CPU core in the Owned state switches to the Invalid state, the first state of other CPU cores remains unchanged, and the CPU DIE switches to the execution state S003.

[0124] For example, when the CPU DIE is in execution state S007, if a CPU core in the CPU DIE whose first state is Shared initiates a consistent write-back and invalidation operation request, and the state recorder obtains that the first state of multiple CPU cores is Shared, then the CPU DIE does not need to send a consistent write-back and invalidation operation request to the IO DIE, and the CPU DIE remains in state S007; if the state recorder obtains that the first state of only one CPU core is Shared, then the CPU DIE sends a consistent write-back and invalidation operation request to the IO DIE. After the request is completed, the CPU DIE switches to execution state S000.

[0125] For example, when a CPU DIE is in execution state S007, if a CPU core within that CPU DIE desires exclusive access, it initiates a consistent exclusive read request. The Interconnect or on-chip network NOC receives this request and initiates a Snoop data forwarding listener request to the CPU core currently in a valid state, performing an invalid operation to complete the state transition for the first CPU state within that CPU DIE. Then, the CPU DIE sends a consistent exclusive read request to the IO DIE, waits for the IO DIE to return a result, and completes the state transition for the second DIE state. After all requests are completed, if the IO DIE returns a response confirming "no other DIE holds a valid copy of this cache line, and the data currently held by the CPU DIE is consistent with main memory (no dirty data)," the CPU DIE switches to execution state S001. If the IO DIE returns a response confirming "no other DIE holds a valid copy of this cache line, but the data currently held by the CPU DIE is dirty data," the CPU DIE switches to execution state S005.

[0126] For example, when a CPU DIE is in execution state S008, if its second state is Owned and only one CPU core's first state is Owned, and if the Owned CPU core initiates a consistent write-back operation request, the CPU DIE sends the consistent write-back operation request to the IO DIE for processing. After the request is completed, the CPU DIE switches to execution state S007. If the Owned CPU core initiates a consistent write-back and invalid operation request, the CPU DIE sends the consistent write-back and invalid operation request to the IO DIE for processing. After the request is completed, the CPU DIE switches to execution state S000.

[0127] For example, when a CPU DIE is in execution state S008, if its second state is Owned, one CPU core's first state is Owned, and at least one CPU core's first state is Shared: If an Owned CPU core initiates a consistent write-back operation request, the CPU DIE sends the request to the IO DIE for processing. After the request is completed, the CPU DIE switches to execution state S007. If an Owned CPU core initiates a consistent write-back and invalidation operation request, the CPU DIE sends the request to the IO DIE for processing. After the request is completed, the CPU DIE switches to execution state S000. If a Shared CPU core initiates an invalidation operation request, no request needs to be sent to the IO DIE; the CPU DIE handles the request internally, and the CPU DIE switches to execution state S005.

[0128] It should be added that, such as Figure 3 As shown, if CPU DIE2 is in the Owned state, CPU DIE3 is in the Shared state, and CPU DIE4 is in the Shared state, then a CPU core in CPU DIE7 within BLOCK0 initiates a consistent shared read request. This consistent shared read request enters IO DIE0 through the Router DIE. After reading the state recorder, IO DIE0 identifies the shared data in CPU DIE4 within BLOCK1. Therefore, IO DIE0 sends a Snoop data pre-listening request to CPU DIE4, transferring the data from CPU DIE4 to CPU DIE7.

[0129] It should be added that, such as Figure 3 As shown, the state recorder of IO DIE0 does not need to record the state of the Device. When the Device initiates a consistent read operation request, if the state recorder of IO DIE0 records that there is shared data on the CPU DIE, the data is acquired according to the principle of proximity to IO DIE0.

[0130] In summary, the DIE-to-DIE cache consistency processing method provided in this application, by constructing an interconnected architecture of multiple CPU DIEs and multiple IO DIEs, and combining a hierarchical state management mechanism of first state-second state-third state, breaks through the limitation of strong coupling between state records and the number of DIEs in traditional architectures. It can flexibly configure the expansion requirements of multiple DIEs of different scales, providing a feasible architectural reference for the construction of ultra-large-scale multi-DIE systems. When performing cache consistency maintenance based on three-layer state data, the target CPU DIE can call its local first and second states, reducing the number of interactions and data transfer volumes for cross-DIE consistency requests. The third state of the IO DIE only records cache state changes, not the full state. Compared to the existing technology where the IO DIE needs to store the full state, this accelerates the synchronization speed of dirty data in the cache to memory, significantly reduces the overall transmission latency of data interaction between DIEs, greatly reduces the capacity requirement of the state recorder for cache consistency maintenance on the IO DIE, reduces the hardware design complexity and manufacturing cost of the IO DIE, and reduces the system functional overhead caused by invalid consistency requests.

[0131] Figure 6 This is a schematic diagram of the structure of a data sharing acceleration device provided in an embodiment of this application. Figure 6 As shown, the data sharing acceleration device 600 includes:

[0132] Interconnect module 601 is used to establish an interconnect architecture that includes multiple CPU DIEs and multiple IO DIEs, wherein each CPU DIE integrates multiple CPU cores;

[0133] The status recording module 602 is used to acquire the first and second states within each CPU DIE and the third state of each IO DIE in real time. The first state is used to record the cache line state of a single CPU core, the second state is used to record the cache line state between different DIEs, and the third state is used to record the cache state changes of all CPU DIEs.

[0134] The request processing module 603 is used to respond to a cache access request initiated by at least one CPU core in any CPU DIE, and to perform cache consistency maintenance based on a first state, a second state, and a third state, wherein the CPU DIE that initiated the cache access request is taken as the target CPU DIE.

[0135] Figure 7 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0136] like Figure 7 As shown, the electronic device 700 includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a memory 706 into a random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the electronic device 700. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0137] The following components are connected to I / O interface 705: memory 706 including hard disk; and communication section 707 including network interface card such as LAN (Local Area Network) card, modem, etc., communication section 707 performs communication processing via a network such as the Internet; drive 708 is also connected to I / O interface 705 as needed.

[0138] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication section 707. When the computer program is executed by the processor 701, it performs the functions defined in the methods of this application.

[0139] In an exemplary embodiment, a storage medium including instructions is also provided, such as a memory including instructions, which can be executed by a processor 701 of an electronic device 700 to perform the above-described method. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0140] In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can transmit, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wireline, optical fiber, RF, etc., or any suitable combination thereof.

[0141] For cases where the corresponding electronic device can be a chip or a chip system, please refer to [reference needed]. Figure 8 The diagram shows the result of the chip. Figure 8 The chip shown includes one or more interface circuits 802 and one or more processors 801; the interface circuits 802 are used to receive signals from the memory of the electronic device and send signals to the processors 801. The signals include computer instructions stored in the memory 803. When the processors 801 execute the computer instructions, the electronic device executes the DIE cache coherency processing method proposed in the embodiments of this application.

[0142] In this embodiment of the disclosure, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods disclosed in the above embodiments.

[0143] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0144] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for handling cache consistency between DIEs, characterized in that, include: An interconnect architecture is established that includes multiple CPU DIEs and multiple IO DIEs, wherein each CPU DIE integrates multiple CPU cores; The system acquires the first and second states within each CPU DIE and the third state of each IO DIE in real time. The first state is used to record the cache line state of a single CPU core, the second state is used to record the cache line state between different DIEs, and the third state is used to record the cache state changes of all CPU DIEs. In response to at least one CPU core within any CPU DIE initiating a cache access request, cache consistency maintenance is performed based on the first state, the second state, and the third state, wherein the CPU DIE that initiated the cache access request is taken as the target CPU DIE.

2. The method according to claim 1, characterized in that, The first and second states within each CPU DIE satisfy the following correspondence: If the second state is Invalid, the first state of all CPU cores is Invalid; If the second state is Exclusive, then only one CPU core has the first state of Exclusive, and the first states of the other CPU cores are all Invalid. If the second state is Exclusive, then only one CPU core has the first state of Modified, and the first states of the other CPU cores are all Invalid. If the second state is Exclusive, then one CPU core must have a first state of Shared, and the first states of the other CPU cores are a random combination of Shared and Invalid. If the second state is Exclusive, then only one CPU core among all CPU cores has the first state as Owned, and the first states of the other CPU cores are a random combination of Shared and Invalid. If the second state is Modified, then only one CPU core has the first state of Modified, and the first states of the other CPU cores are all Invalid. If the second state is Modified, then only one CPU core has the first state of Owned, and the first states of the other CPU cores are a random combination of Shared and Invalid. If the second state is Shared, then one CPU core must have the first state as Shared, and the first states of the other CPU cores are a random combination of Shared and Invalid. If the second state is Owned, then only one CPU core has the first state as Owned, while the first states of the other CPU cores are a random combination of Shared and Invalid.

3. The method according to claim 1, characterized in that, The third state is used to record all cache state changes of CPU DIEs, including: Based on the transmission distance between each CPU DIE and IO DIE in the board-level DIE layout, each CPU DIE is divided into different distance levels; The cache state of the corresponding CPU DIE is stored sequentially based on the distance hierarchy, so that each CPU DIE is retrieved from near to far according to the transmission distance between it and the IO DIE.

4. The method according to any one of claims 1-3, characterized in that, The step of responding to at least one CPU core within any CPU die initiating a cache access request, and performing cache consistency maintenance based on the first state, the second state, and the third state, includes: In response to a cache access request being a consistent exclusive read request, the IO DIE queries its own state logger; if its own state logger indicates that the cache status of all CPU DIEs is Invalid, the IO DIE reads the memory data and feeds the memory data back to the CPU DIE. After completing the reading of memory data and feeding the memory data back to the CPU DIE, the IO DIE sets the second state of the target CPU DIE to Exclusive and the first state of the CPU core in the target CPU DIE that initiated the consistent exclusive read request to Exclusive.

5. The method according to any one of claims 1-3, characterized in that, The step of responding to at least one CPU core within any CPU die initiating a cache access request, and performing cache consistency maintenance based on the first state, the second state, and the third state, includes: In response to a cache access request being a consistent shared read request, the IO DIE queries its own state logger and selects CPU DIEs with valid states as the initial source CPU DIEs. The valid states include Exclusive, Modified, Shared, and Owned. Based on the transmission distance between multiple initial source CPU DIEs and IO DIEs, and combined with the block to which the target CPU DIE belongs, the IODIE sends a Snoop data forwarding listening request to the initial source CPU DIE that meets the requirements in order to perform cache consistency maintenance.

6. The method according to claim 5, characterized in that, The step of sending a Snoop data forwarding request from the IO DIE to the qualified initial source CPU DIE to perform cache consistency maintenance, based on the transmission distance between multiple initial source CPU DIEs and the IO DIE, and combined with the block to which the target CPU DIE belongs, includes: By quantifying the transmission distance of multiple initial source CPU DIEs and combining the sensitivity of the block to transmission latency of the target CPU DIE that initiated the cache access request, a preset priority rule is used to determine the comprehensive score of multiple initial source CPU DIEs. The initial source CPU DIE with the highest comprehensive score is selected as the candidate source CPU DIE. The IO DIE sends a Snoop data forward listening request to the candidate source CPU DIE to perform cache consistency maintenance.

7. The method according to claim 6, characterized in that, After the IO DIE sends the Snoop data forwarding listening request to the candidate source CPU DIE, it also includes: The candidate source CPU DIE transfers the data that needs to be shared for reading to the target CPU DIE; If the second state of the candidate source CPU DIE is Exclusive and the first state of multiple CPU cores is Owned, update the second state of the candidate source CPU DIE to Owned and update the second state of the target CPU DIE to Shared. If the second state of the candidate source CPU DIE is Exclusive and the first state of only a single CPU core is valid, the second state of both the candidate source CPU DIE and the target CPU DIE is updated to Shared. The valid states include Exclusive, Modified, Shared, and Owned. If the second state of the candidate source CPU DIE is Modified, update the second state of the candidate source CPU DIE to Owned, and update the second state of the target CPU DIE to Shared.

8. The method according to claim 6, characterized in that, The preset priority rule satisfies one of the following conditions: Prioritize retrieving the data that needs to be shared from the CPU DIE whose block memory is in an active state; If all CPU DIEs in the block to which the target CPU DIE belongs are invalid, the CPU DIE in another block with the shortest transmission distance and a valid state is selected as the initial source CPU DIE based on the IO DIE's own state recorder.

9. The method according to any one of claims 1-3, characterized in that, The step of responding to at least one CPU core within any CPU die initiating a cache access request, and performing cache consistency maintenance based on the first state, the second state, and the third state, further includes: In response to a cache access request being a consistency invalid operation request, the IO DIE queries its own state recorder. If there are multiple valid CPU cores in the candidate source CPU DIE, the first state of the multiple valid CPU cores is updated to Invalid. The valid states include Exclusive, Modified, Shared, and Owned. In response to a cache access request being a consistency invalidation operation request, the IO DIE queries its own state recorder. If the candidate source CPU DIE has only one CPU core with a valid state, the consistency invalidation operation request is transmitted through the IO DIE, and the CPU core with a valid state that has completed the cache access request is updated to Invalid. In response to a cache access request as a consistent write-back operation request, if there are multiple CPU cores in the Shared state in the candidate source CPU DIE, the consistent write-back operation request is transmitted through the IO DIE, and the multiple CPU cores that have completed the cache access request are still kept in the Shared state. In response to a cache access request as a consistent write-back operation, if the candidate source CPU DIE has only one CPU core in the Shared state, the consistent write-back operation request is transmitted through the IO DIE; if the candidate source CPU DIE retains the local data, the second state of the CPU core that completed the cache access request is updated to Exclusive; if the candidate source CPU DIE does not retain the local data, the second state of the CPU core that completed the cache access request is updated to Invalid. In response to a cache access request being a consistent write-back and invalid operation, if there are multiple CPU cores in the Shared state in the candidate source CPU DIE, the cache access request will be converted into a write-back operation. In response to a cache access request that is a consistent write-back and invalid operation, if the candidate source CPU DIE has only one CPU core in the Shared state, the consistent write-back and invalid operation request is transmitted through the IO DIE, and the CPU core that completed the cache access request is updated from the Shared state to Invalid.

10. A data sharing acceleration device, characterized in that, include: An interconnect module is used to establish an interconnect architecture that includes multiple CPU DIEs and multiple IO DIEs, wherein each CPU DIE integrates multiple CPU cores; The status recording module is used to acquire the first and second states within each CPU DIE and the third state of each IO DIE in real time. The first state is used to record the cache line state of a single CPU core, the second state is used to record the cache line state between different DIEs, and the third state is used to record the cache state changes of all CPU DIEs. The request processing module is configured to respond to a cache access request initiated by at least one CPU core within any CPU DIE, and to perform cache consistency maintenance based on the first state, the second state, and the third state, wherein the CPU DIE that initiated the cache access request is designated as the target CPU DIE.

Images