Credit management method and system for cross-DIE data transmission flow control

Abstract

The invention discloses a credit management method and system for cross-DIE data transmission flow control. The credit management method comprises the following steps: (1) establishing a double-credit pool structure; (2) a remote credit management process; and (3) a local credit management process. The credit management system comprises a cross-DIE interface module, a credit management module, a protocol processing module and a buffer queue management module. According to the invention, the bidirectional flow control of various types of data transmitted across DIE is realized, and the protocol overhead is reduced on the premise of ensuring the flow control effect.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of data transmission, and particularly relates to a credit management method and system for cross-DIE data transmission flow control. BACKGROUND

[0002] With the rapid growth of high-performance computing demand, the bottleneck of traditional single-chip in area, yield and process selection is increasingly prominent, and modern digital chip design gradually evolves to Chiplet architecture. This architecture uses Die-to-Die interconnection technology to package multiple dies with different functions into a system chip, and selects the appropriate process according to the needs of each functional unit, without the need to uniformly adopt advanced processes, thereby reducing design costs, improving design iteration flexibility and chip yield, and widely used in AI accelerator, multi-core processor and other fields. However, compared with the traditional on-chip bus, the Die-to-Die physical link often has higher delay and more complex electrical characteristics, so it is necessary to develop more efficient Chiplet interconnection technology, and the Chiplet interconnection interface is a key technical element. UCIe standard (Universal Chiplet Interconnect Express) as an industry standard for unified Chiplet interconnection interface, lays an important foundation for the development of Chiplet ecosystem. UCIe is usually divided into three layers, namely protocol layer, adapter layer and physical layer, among which the protocol layer is responsible for defining the rules and flow control of inter-chip communication, such as mapping existing PCIe / CXL protocols, and can also support custom protocols (such as AXI, CHI) through Streaming protocol extension, providing flexible optimization space for upper layer implementation. At the same time, the flow control management of the protocol layer is mainly responsible for regulating the receiving and sending rates of the data packets of the Chiplet sending end and receiving end to match, which is crucial for reducing the data packet sending delay of the sending end and improving the utilization rate of the transmission bandwidth between Chiplets.

[0003] Traditional ready / valid handshake protocols require the sender to wait for a readiness signal from the receiver before each data transmission. This synchronization mechanism can negatively impact transmission efficiency in cross-DIE (Digital Interconnection) transmissions due to long signal propagation delays. Credit-based flow control, a widely used communication mechanism in Network-on-Chip (NoC), is essentially a "buffer capacity reservation" protocol. It manages data transmission by maintaining credit counts at both the sender and receiver. Before its local buffer overflows, the receiver informs the sender of the number of data units (credits) it can continue receiving. The sender then deducts credits before transmitting data, ensuring that it sends multiple data packets consecutively only when the receiver's buffer has sufficient space, without waiting for individual acknowledgments for each packet. This prevents buffer overflows and fully utilizes the bandwidth resources of the cross-DIE link. Furthermore, the credit mechanism provides better traffic prediction capabilities, allowing the sender to plan subsequent data transmission strategies based on the current credit count, which is crucial for optimizing overall system performance.

[0004] Currently, there is some accumulation in cross-chip data transmission flow control technology. Generally, an end-to-end flow control scheme is adopted, which achieves full-link traffic management by embedding flow control information in high-level protocols. However, this method requires special credit update messages to synchronize the credit status of both parties, which often introduces large protocol overhead and consumes certain bandwidth resources. It is not suitable for relatively simplified application scenarios such as data transmission between DIEs. Summary of the Invention

[0005] The purpose of this invention is to solve the above-mentioned technical problems existing in the prior art, and to provide a credit management method and system for cross-DIE data transmission flow control, which realizes bidirectional flow control for transmitting multiple types of data across DIE, and reduces protocol overhead while ensuring the flow control effect.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A credit management method for cross-DIE data transmission flow control, characterized by comprising the following steps: (1) Establish a dual credit pool structure: A symmetrical dual credit pool structure is established between the sending end and the receiving end. The dual credit pool structure includes a local credit pool and a remote credit pool. (2) Remote credit management process: (2.1) When the local DIE transmitter needs to send a data packet to the DIE receiver on the other side, it queries the remote credit counter of the corresponding type in the remote credit pool according to the type of data to be sent, and then decides whether the local DIE sends a data packet to the DIE receiver on the other side according to the value of the remote credit counter. (2.2) When the DIE receiver on the other side receives the data packet, it extracts the credit field from the protocol header of the data packet and parses it. Based on the credit type and credit value obtained from the parsing, it updates the remote credit counter values ​​of each type in the remote credit pool. (3) Local credit management process: (3.1) When the local buffer finishes data processing and releases the buffer space, the credit value is increased in the local credit counter of the corresponding type according to the type and size of the released buffer, and the local credit information is updated. (3.2) When the local DIE sender needs to send a data packet to the DIE receiver on the other side, it encodes the credit information of each type in the current local credit pool into the credit field of the protocol header and notifies the DIE receiver on the other side of the local credit status through data packet transmission.

[0007] Furthermore, in step (2.1), if the value of the remote credit counter is greater than 0, the corresponding type of remote credit is consumed, and the local DIE sender sends a data packet to the remote DIE receiver; if the value of the remote credit counter is equal to 0, the data packet is temporarily stored in the local sending waiting queue until the local DIE sender receives the supplementary credit information from the remote DIE, and then the local DIE sender sends the data packet again.

[0008] Furthermore, both the local credit pool and the remote credit pool in step (1) include four sub-credit pools, which correspond to four data transmission types: REQ, RSP, DATA, and SNP.

[0009] Furthermore, each sub-credit pool uses an n-bit wide credit counter, with the credit value in the counter ranging from 0 to 2. n .

[0010] Furthermore, in step (2.2), the credit field is embedded at a fixed offset position in the protocol layer reserved area of ​​any UCIe standard data packet.

[0011] Furthermore, the credit field in step (2.2) includes four subfields, which correspond to the credit values ​​of four data types: REQ, RSP, SNP, and DATA.

[0012] Furthermore, the credit information coding in steps (3.1) and (3.2) adopts the downward coding principle, and the coding value is determined according to the range of credit quantity.

[0013] Furthermore, the credit field uses a fixed-length 16-bit format and is evenly distributed across the four data types: The 0th to 3rd digits are used for REQ type credit coding; Positions 4-7 are used for RSP type credit coding; Positions 8-11 are used for SNP type credit coding; Bits 12-15 are used for credit encoding of the DATA type.

[0014] A credit management system for cross-DIE data transmission flow control, characterized in that it includes: a cross-DIE interface module, a credit management module, a protocol processing module, and a buffer queue management module; Cross-DIE interface module, used to establish physical connection with the other DIE and transmit data; The credit management module is used to maintain the two-way credit status and perform credit allocation, consumption, and recovery operations; The protocol processing module is used to encode credit information into the protocol header of data packets when sending data and to decode credit information from the protocol header of data packets when receiving data. The buffer queue management module is used to manage the local data buffer and report buffer status changes to the credit management module.

[0015] Furthermore, the credit management module includes a remote credit pool and a local credit pool. The remote credit pool is used to manage the buffer resource status of the DIE on the other side, while the local credit pool is used to manage the buffer resource status of the DIE on the local side.

[0016] The present invention, by adopting the above-described technical solution, has the following beneficial effects: 1. It achieves bidirectional flow control for transmitting various types of data across DIEs, reducing protocol overhead while ensuring flow control effectiveness.

[0017] 2. The compatibility issues between the credit-based flow control management mechanism and the UCIe standard in cross-DIE data transmission have been resolved. Attached Figure Description

[0018] The present invention will be further described below with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the inter-core communication architecture in this invention; Figure 2 This is a schematic diagram of the dual credit pool flow control in this invention; Figure 3 This is a flowchart of the remote credit management process in this invention; Figure 4 This is a flowchart of the local credit management process in this invention; Figure 5These are schematic diagrams of three typical UCIe protocol packet formats. Figure 6 A schematic diagram of a 68B extended data packet format structure compatible with the UCIe standard; Figure 7 This is a schematic diagram of the bit allocation method and encoding rules of the credit field in this invention. Detailed Implementation

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. 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 skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0022] The definitions of the technical terms described in this invention are shown in the table below: English Abbreviations Glossary NoC Network-on-Chip: An interconnect architecture for communication between cores in a multi-core processor or integrated circuit, enabling efficient data transfer through routers and links. SoC System on Chip: Integrating key components of a computer or other electronic system (such as CPU, GPU, memory controller, I / O interface, DSP, etc.) on a single chip, commonly found in mobile phones, tablets, embedded devices, and modern PC processors. DIE Die: A single silicon chip in integrated circuit manufacturing. Chiplet Chiplet: A type of die that meets specific functional requirements, packaged together with the underlying base chip through die-to-die internal interconnection technology to form a system chip, implementing a new form of IP reuse. UCIe Universal Chiplet Interconnect Express: An open standard for cross-DIE communication between Chiplets, supporting high bandwidth and low latency. CHI Coherent Hub Interface: A high-performance cache coherence protocol defined by ARM. Flit Flit: The basic unit of data transmission. Rsp Response: A flit type used to transmit response data. Req Request: A flit type used to initiate data requests. Data Data: A flit type used to transmit primary data load. Snp Snoop: A flit type used in cache coherence protocols to monitor shared data status. A credit management system for cross-DIE data transmission flow control includes: a cross-DIE interface module, a credit management module, a protocol processing module, and a buffer queue management module. The cross-DIE interface module is used to establish a physical connection with the opposite DIE and transmit data. The credit management module is used to maintain the bidirectional credit status and perform credit allocation, consumption and recycling operations. The credit management module includes a remote credit pool and a local credit pool. The remote credit pool is used to manage the buffer resource status of the DIE on the other side, and the local credit pool is used to manage the buffer resource status of the DIE on the local side. Bidirectional fine-grained flow control for cross-DIE data transmission is realized through local credit counting management.

[0023] The sending end of the protocol processing module is used to package and send data, while the receiving end of the protocol processing module is responsible for receiving and parsing data.

[0024] When sending data, the sending end of the protocol processing module arbitrates the credit values ​​of various types in the remote credit pool to determine the data to be sent, and encodes the credit information of the local credit pool into the protocol header of the data packet; when receiving data, the receiving end of the protocol processing module decodes the credit information from the protocol header of the data packet to supplement the credit value of the remote credit pool.

[0025] The buffer queue management module is used to manage the local data buffer and report buffer status changes to the credit management module.

[0026] A credit management method for cross-DIE data transmission flow control includes the following steps: (1) Establish a dual credit pool structure: A symmetrical dual credit pool structure is established between the sending end and the receiving end. The dual credit pool structure includes a local credit pool and a remote credit pool. Both the local credit pool and the remote credit pool include four sub-credit pools according to the data flow type. The four sub-credit pools correspond to four data transmission types: REQ, RSP, DATA, and SNP. Independent credit management mechanisms are maintained for these four types to achieve refined flow control.

[0027] The remote credit pool comprises four independent credit counters: REQ_Credit_Remote, used to manage the status of the peer DIE request type buffer; RSP_Credit_Remote, used to manage the status of the peer DIE response type buffer; DATA_Credit_Remote, used to manage the status of the peer DIE data type buffer; and SNP_Credit_Remote, used to manage the status of the peer DIE listening type buffer. Each sub-credit pool uses an n-bit wide credit counter, with the credit value in the counter ranging from 0 to 2. n , where n is a positive integer.

[0028] The internal structure of the local credit pool is consistent with that of the remote credit pool, including four independent credit counters: REQ_Credit_Local, used to manage the local DIE request type buffer status; RSP_Credit_Local, used to manage the local DIE response type buffer status; DATA_Credit_Local, used to manage the local DIE data type buffer status; and SNP_Credit_Local, used to manage the local DIE listening type buffer status. Each sub-credit pool uses an n-bit wide credit counter, with the credit value in the counter ranging from 0 to 2. n , where n is a positive integer.

[0029] (2) Remote credit management process, which is responsible for controlling the decision-making logic for sending data to the counterpart DIE, such as Figure 2 and Figure 3As shown: (2.1) When the local DIE sender needs to send a data packet to the DIE receiver on the other side, it queries the remote credit counter of the corresponding type in the remote credit pool according to the type of data to be sent, and then decides whether the local DIE sends the data packet to the DIE receiver on the other side based on the value of the remote credit counter.

[0030] If the value of the remote credit counter is greater than 0, it indicates that the other side DIE has enough buffer space to receive this type of data. The cross-DIE communication module consumes one unit of the corresponding type of remote credit, and the local DIE sends a data packet to the receiving end of the other side DIE. If the value of the remote credit counter is equal to 0, it indicates that the corresponding type buffer space of the DIE on the other side is full. The data packet is temporarily stored in the local sending waiting queue until the DIE on this side receives the supplementary credit information from the DIE on the other side, and then the DIE on this side sends the data packet.

[0031] This credit-based pre-checking transmission control mechanism effectively prevents data loss caused by overflow of the DIE buffer on the other side.

[0032] (2.2) When the DIE receiver on the other side receives the data packet, it extracts the credit field from the protocol header of the data packet and parses it. Based on the credit type and credit value obtained from the parsing, it updates the remote credit counter values ​​of each type in the remote credit pool. (3) Local credit management process, which is responsible for maintaining the buffer status of the local DIE, that is, it needs to report the available credit value information of the local DIE to the DIE on the other side, such as Figure 2 and Figure 4 As shown: (3.1) When the cross-DIE communication module receives a data packet from the other side DIE and parses it, it sends the parsed data packet to the local NoC for processing. The corresponding local buffer space is released, triggering the update operation of the local credit counter.

[0033] The system adds credit values ​​to the corresponding local credit counter based on the type and size of the released buffer, enabling the credit values ​​of the local credit pool to be dynamically updated according to the actual usage of the local DIE buffer.

[0034] (3.2) When the local DIE sender sends a data packet to the DIE receiver on the other side, it encodes the credit information of each type in the current local credit pool into the credit field of the protocol header and notifies the DIE receiver on the other side of the local credit status through data packet transmission.

[0035] It can promptly notify the counterpart DIE of credit changes on this side, enabling the counterpart DIE to continue sending more data; credit information is transmitted simultaneously with data transmission, without the need to define and implement dedicated credit message types, achieving zero additional overhead for credit communication flow control.

[0036] The two management processes synchronize information and coordinate status through the credit field in the protocol header, forming a continuously running two-way credit information exchange loop, which ensures the real-time synchronization and accurate maintenance of the dual credit pool status.

[0037] like Figure 1 As shown, the credit management system in this invention is built on a standardized inter-chip communication architecture, employing at least two symmetrical DIE architectures. Each DIE integrates a local on-chip network (NoC) and a cross-DIE communication module, with DIE 0 and DIE 1 connected via a physical link.

[0038] The interface between the local NoC and the cross-DIE communication module follows the standard CHI protocol specification, supporting four data transmission types: REQ (request), RSP (response), DATA (data), and SNP (listen). The cross-DIE communication module undertakes the key functions of data transmission and flow control between DIEs, and is mainly divided into three layers: ① Protocol layer, as the top layer, is responsible for the actual protocol flow processing, flow control, etc.; ② Adapter layer, mainly responsible for error detection, retransmission, link management, etc.; ③ Physical layer, as the bottom layer, is responsible for the link signal transmission between DIEs.

[0039] As the core execution layer for data transmission and flow control management, the protocol layer packages various data and control information generated by the local NoC into a standard data packet format in the TX direction and then passes it to the adapter layer; in the RX direction, the protocol layer parses the data packets received from the DIE on the other side and then passes them to the local NoC side.

[0040] The bidirectional data transmission management is monitored and maintained in real time by the credit pool of each DIE. The cross-DIE communication module within each DIE contains a dual credit pool management mechanism based on the protocol layer: On the DIE 0 side, the cross-DIE communication module maintains a remote credit pool (Remote Pool 0) for managing the buffer state of the DIE 1 side and a local credit pool (Local Pool 0) for managing the buffer state of the DIE 0 side; On the DIE 1 side, the cross-DIE communication module also maintains a remote credit pool (Remote Pool 1) for managing the buffer state of the DIE 0 side and a local credit pool (Local Pool 1) for managing the buffer state of the DIE 1 side.

[0041] This symmetrical design ensures that both sides can make independent flow control decisions. When the protocol layer detects that data needs to be sent to the other side's DIE, it will only initiate data transmission if it confirms that the other side's DIE has sufficient buffer space. At the same time, when packaging the data to be sent, the local remaining buffer resource information will be added to the protocol header of the data packet to achieve synchronization of bidirectional credit status.

[0042] The credit management system in this invention fully considers compatibility with the UCIe standard when designing protocol extensions, such as... Figure 5 The three typical UCIe protocol packet formats shown depict different layers of control information carried in different areas of the packet, resolving the compatibility issue between the credit-based flow control management mechanism and the UCIe standard in cross-DIE data transmission. The gray area represents padding space reserved by the UCIe standard for the protocol layer, but without specifying a concrete padding format. Therefore, in addition to the data message itself, a credit field can be defined within the reserved area to carry credit information from the dual credit pool. The blank bytes represent the portion where the adapter layer participates in the padding process. Both the adapter and physical layers maintain transparent transmission of the credit field content, without any modification or parsing operations, ensuring end-to-end credit information integrity.

[0043] The credit field uses a 16-bit fixed-length format. This format is not limited to the data packet type and can be flexibly embedded into a fixed offset position in the protocol layer reserved area of ​​any UCIe standard data packet. The specific offset can be configured and adjusted according to the protocol layer structure in different data packets.

[0044] The internal structure of the credit field is divided into four 4-bit subfields, which correspond to the credit quantity codes of four data types: REQ, RSP, DATA, and SNP. The encoding and parsing rules can be kept consistent across different types of data packets.

[0045] like Figure 6 The diagram shows a 68B extended packet format compatible with the UCIe standard. This format sets the Flit block to a fixed length of 62B and configures a Protocol Header space of two bytes at the initial position of each Flit block. This header is used as a credit field to fill credit information and is used as signaling for end-to-end flow control. In this case, n=4 and the maximum credit value is 16.

[0046] like Figure 6 As shown, the fixed offset of the credit field position is shown. The dark part PH is offset by 4 bytes each time, PH1 B0 (byte2) ---> PH2 B0 (byte6), and the cumulative offset can be cycled back to the position of PH1 B0 (byte2).

[0047] like Figure 7As shown, the credit field is evenly distributed among the four data types: bits 0-3 are used for REQ type credit codes, bits 4-7 for RSP type credit codes, bits 8-11 for SNP type credit codes, and bits 12-15 for DATA type credit codes. This allocation method ensures the integrity and independence of credit information of various data types.

[0048] like Figure 7 As shown, different encoded values ​​correspond to different credit values. The credit field encoding process at the sending end is as follows: When sending a data packet, the cross-DIE communication module at the sending end reads the current credit value of each type in the local credit pool, adopts a downward encoding principle, and determines the encoding value according to the range of the credit value. For example, if the credit value is between 4 and 7, the encoding value corresponds to 0010. The credit field decoding process at the receiving end is as follows: When the receiving end of the other DIE receives the data packet, the cross-DIE communication module extracts the 16-bit credit field from the protocol header and separates it into four independent credit values ​​through decoding.

[0049] The above are merely specific embodiments of the present invention, but the technical features of the present invention are not limited thereto. Any simple changes, equivalent substitutions, or modifications made based on the present invention to solve essentially the same technical problems and achieve essentially the same technical effects are all covered within the protection scope of the present invention.

Claims

1. A credit management method for cross-DIE data transmission flow control, characterized in that... The steps include: (1) Establishing a dual credit pool structure: A symmetrical dual credit pool structure is established between the sending end and the receiving end. The dual credit pool structure includes a local credit pool and a remote credit pool. (2) Remote credit management process: (2.1) When the local DIE sender needs to send a data packet to the remote DIE receiver, it queries the remote credit counter of the corresponding type in the remote credit pool according to the type of data to be sent, and then decides whether the local DIE sends the data packet to the remote DIE receiver according to the value of the remote credit counter; (2.2) When the remote DIE receiver receives the data packet, it extracts the credit field from the protocol header of the data packet and parses it, and updates the value of each type of remote credit counter in the remote credit pool according to the credit type and credit value obtained from the parsing; (3) Local credit management process: (3.1) When the local buffer completes data processing and releases the space of the buffer, it adds the credit value in the local credit counter of the corresponding type according to the type and size of the released buffer, and updates the local credit information; (3.2) When the local DIE sender sends a data packet to the DIE receiver on the other side, it encodes the credit information of each type in the current local credit pool into the credit field and notifies the DIE receiver on the other side of the local credit status through data packet transmission.

2. The credit management method for cross-DIE data transmission flow control according to claim 1, characterized in that: In step (2.1), if the value of the remote credit counter is greater than 0, the corresponding type of remote credit is consumed, and the local DIE sender sends a data packet to the remote DIE receiver; if the value of the remote credit counter is equal to 0, the data packet is temporarily stored in the local sending waiting queue until the local DIE sender receives the supplementary credit information from the remote DIE, and then the local DIE sender sends the data packet.

3. A credit management method for cross-DIE data transmission flow control according to claim 1, characterized in that: The local credit pool and remote credit pool in step (1) each include four sub-credit pools, which correspond to four data transmission types: REQ, RSP, DATA, and SNP.

4. A credit management method for cross-DIE data transmission flow control according to claim 3, characterized in that: Each sub-credit pool uses an n-bit wide credit counter, with the credit value in the counter ranging from 0 to 2. n .

5. A credit management method for cross-DIE data transmission flow control according to claim 1, characterized in that: In step (2.2), the credit field is embedded at a fixed offset position in the protocol layer reserved area of ​​any UCIe standard data packet.

6. A credit management method for cross-DIE data transmission flow control according to claim 1, characterized in that: The credit field in step (2.2) includes four subfields, which correspond to the credit values ​​of four data types: REQ, RSP, SNP, and DATA.

7. A credit management method for cross-DIE data transmission flow control according to claim 6, characterized in that: The credit information coding in steps (3.1) and (3.2) adopts the downward coding principle, and the coding value is determined according to the range of credit quantity.

8. A credit management method for cross-DIE data transmission flow control according to claim 6, characterized in that: The credit field uses a fixed-length 16-bit format and is evenly distributed among the four data types: bits 0-3 are used for REQ type credit codes; bits 4-7 are used for RSP type credit codes; bits 8-11 are used for SNP type credit codes; and bits 12-15 are used for DATA type credit codes.

9. A credit management system for cross-DIE data transmission flow control, characterized in that, include: Cross-DIE interface module, credit management module, protocol processing module, and buffer queue management module; The cross-DIE interface module is used to establish a physical connection with the other DIE and transmit data; the credit management module is used to maintain the bidirectional credit status and perform credit allocation, consumption and recycling operations; the protocol processing module is used to encode credit information into the protocol header of the data packet when sending data and to decode credit information from the protocol header of the data packet when receiving data; the buffer queue management module is used to manage the local data buffer and report buffer status changes to the credit management module.

10. A credit management system for cross-DIE data transmission flow control according to claim 9, characterized in that: The credit management module includes a remote credit pool and a local credit pool. The remote credit pool is used to manage the buffer resource status of the DIE on the other side, and the local credit pool is used to manage the buffer resource status of the DIE on the local side.

Images