A data transmission method and an on-chip network system
By using a data transmission method between requesting nodes and home nodes in an on-chip network and utilizing total write data volume indication information, the contradiction between bandwidth and order preservation is resolved, achieving efficient data transmission, avoiding deadlock and out-of-order delivery, and improving system performance.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHIHE COMPUTING TECHNOLOGY (HANGZHOU) CO LTD
- Filing Date
- 2026-02-09
- Publication Date
- 2026-05-26
AI Technical Summary
In modern high-performance chip design, on-chip networks (NoC) face deadlock risks and performance degradation when balancing data transmission bandwidth and order preservation. This is especially true in PCIe point-to-point communication, where existing consistency protocols struggle to effectively address these issues.
By sending a write request containing an indication of the total amount of data to be written to the home node, the home node returns the allowed amount of data based on the data buffer status. The requesting node then sends data based on this information, avoiding the splitting of large amounts of data into multiple smaller requests and reducing the number of request messages generated.
It significantly reduces the number of request packets generated in the on-chip network, improves transmission efficiency and bandwidth utilization, avoids deadlock and out-of-order issues, and improves the system's throughput performance.
Smart Images

Figure CN122086829A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of data transmission technology, and in particular to a data transmission method and an on-chip network system. Background Technology
[0002] In modern high-performance chip designs, on-chip networks (NoC) typically support the mounting of PCIe devices, enabling direct point-to-point (P2P) communication between these devices without CPU intervention. This type of access typically involves the PCIe master (the device initiating the P2P communication) sending a series of continuous bursts of data to the PCIe slave (the device receiving the P2P communication). This data transmission requires both high bandwidth and strict order preservation.
[0003] However, maintaining order, as a timing constraint, limits the concurrency of data packets; while relaxing transmission constraints to increase bandwidth can easily lead to out-of-order data. Once out-of-order data occurs, it may trigger deadlock conditions, causing the entire system to crash. Therefore, balancing bandwidth and order maintenance requires, on the one hand, that the architecture of on-chip networks adopt more complex and sophisticated deadlock prevention mechanisms, which are difficult to cover all rare scenarios in verification. On the other hand, the consensus protocols currently used in on-chip networks exhibit a sharp performance degradation in application scenarios when implementing point-to-point communication. Summary of the Invention
[0004] In view of this, embodiments of the present disclosure provide a data transmission method and an on-chip network system to at least solve or alleviate the above-mentioned problems.
[0005] According to a first aspect of the present disclosure, a data transmission method is provided, applied to PCIe point-to-point communication in a network-on-chip (PCIe), the PCIe comprising: a requesting node and a home node; the method comprising: the requesting node sending a write request to the home node, the write request including indication information for indicating the total amount of write data corresponding to this data transmission; if the home node has a request entry to process the write request, the home node, based on the current data buffer state, returning at least one write request receive response message to the requesting node based on the write request, the write request receive response message indicating the amount of data allowed to be sent by the home node; and the requesting node, based on the received write request receive response message and the amount of data allowed to be sent by the home node, sending corresponding write data to the home node.
[0006] According to a second aspect of the present disclosure, a data transmission method is provided, applied to a home node in a PCIe point-to-point communication on-chip network, the on-chip network including a requesting node and a home node, the method including: receiving a write request sent by the requesting node, the write request including indication information for indicating the total amount of write data corresponding to this data transmission; if the home node has a request entry to process the write request, returning at least one write request receive response message to the requesting node based on the current data buffer state, the write request receive response message indicating the amount of data that the home node is allowed to send; receiving write data sent by the requesting node based on the write request receive response message, the write data corresponding to the data amount information.
[0007] According to a third aspect of the present disclosure, a data transmission method is provided, applied to a requesting node in a PCIe point-to-point communication on-chip network, the on-chip network including a requesting node and a home node. The method includes: sending a write request to the home node, the write request including indication information for indicating the total amount of write data corresponding to this data transmission; if the home node has a request entry to process the write request, receiving at least one write request receive response message returned by the home node based on the write request, the write request receive response message being determined by the home node based on the current data buffer state, the write request receive response message indicating the amount of data that the home node is allowed to send; and sending corresponding write data to the home node based on the received write request receive response message and the amount of data that the home node is allowed to send.
[0008] According to a fourth aspect of the present disclosure, an on-chip network system is provided, the on-chip network comprising: a requesting node and a home node; the requesting node sends a write request to the home node, the write request including indication information for indicating the total amount of write data corresponding to the current data transmission; if the home node has a request entry to process the write request, the home node returns at least one write request receive response message to the requesting node based on the current data buffer state and the write request, the write request receive response message indicating the amount of data allowed to be sent by the home node; the requesting node sends corresponding write data to the home node based on the received write request receive response message and the amount of data allowed to be sent by the home node.
[0009] According to the data transmission scheme of this disclosure embodiment, the requesting node sends a write request to the home node. The write request includes indication information indicating the total amount of write data corresponding to this data transmission. If the home node has a request entry to process the write request, the home node returns at least one write request receive response message to the requesting node based on the current data buffer state and the write request. The write request receive response message indicates the amount of data that the home node is allowed to send. Based on the received write request receive response message and the amount of data that the home node is allowed to send, the requesting node sends the corresponding write data to the home node. This disclosure embodiment enables the requesting node to interact with the entire transmission data channel of the home node through a single message, avoiding the need to break down a large data transmission task into multiple independent small write requests for separate sending. This significantly reduces the number of request messages generated in the on-chip network and reduces the bandwidth consumption of requests. Attached Figure Description
[0010] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings.
[0011] Figure 1 This is a schematic diagram illustrating a data transmission method processing scenario. Figure 2 A schematic diagram illustrating a processing scenario for another data transmission method; Figure 3 This is a schematic diagram illustrating a processing scenario for another data transmission method. Figure 4 This is a schematic diagram illustrating a processing scenario for another data transmission method. Figure 5 This is a schematic diagram illustrating a processing scenario for another data transmission method. Figure 6 This is a schematic diagram illustrating a processing scenario for another data transmission method. Figure 7 This is a schematic diagram illustrating a processing scenario for another data transmission method. Figure 8 This is a schematic diagram illustrating a processing scenario for another data transmission method. Figure 9 This is a schematic diagram illustrating a processing scenario for another data transmission method. Figure 10 This is a flowchart illustrating a data transmission method according to an embodiment of the present disclosure; Figure 11 A schematic diagram illustrating a processing scenario of another data transmission method according to an embodiment of this disclosure; Figure 12 This disclosure provides an embodiment of a data transmission method processing scenario. Figure 13 This disclosure provides an embodiment of a data transmission method processing scenario. Figure 14 This disclosure provides an embodiment of a data transmission method processing scenario. Figure 15 This is a flowchart illustrating another data transmission method according to an embodiment of the present disclosure; Figure 16 This disclosure provides an embodiment of a data transmission method processing scenario. Figure 17 This is a flowchart illustrating another data transmission method according to an embodiment of the present disclosure; Figure 18 This is a flowchart illustrating another data transmission method according to an embodiment of the present disclosure; Figure 19 This is a flowchart illustrating another data transmission method according to an embodiment of the present disclosure; Figure 20 This is a schematic diagram of an on-chip network according to an embodiment of the present disclosure. Detailed Implementation
[0012] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.
[0013] It should be noted that the headings of any section / subsection provided herein are not limiting. Various embodiments are described throughout this document, and embodiments of any type may be included under any section / subsection. Furthermore, embodiments described in any section / subsection may be combined in any way with any other embodiments described in the same section / subsection and / or different sections / subsections.
[0014] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.
[0015] The embodiments of this disclosure may involve user data, data acquisition, and / or use. All of these aspects comply with applicable laws, regulations, and relevant provisions. In the embodiments of this disclosure, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, in implementing the embodiments of this disclosure, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained in accordance with relevant laws and regulations through appropriate means. The specific methods of notification and / or authorization may vary depending on the actual situation and application scenario, and the scope of this disclosure is not limited in this respect.
[0016] In this specification and the embodiments, any processing of personal information will be carried out only under the premise of legality (such as obtaining the consent of the personal information subject, or being necessary for the performance of a contract), and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.
[0017] See Figure 1 The on-chip network (NoC) system architecture applicable to the embodiments of this disclosure includes multiple request nodes (RNs) and home nodes (HNs). These nodes serve as interface modules for connecting PCIe devices to the on-chip network.
[0018] In this embodiment of the disclosure, the PCIe device can act as a master device to send requests and data, or as a slave device to receive requests and data. The PCIe device is typically attached to both a requesting node and a home node simultaneously. Figure 1 The dashed line in the diagram represents a point-to-point transmission path between PCIe device 0 and PCIe device 1.
[0019] The on-chip network's data channel width is set to 32B. For a typical 64B write request, a single write request can carry a maximum of two write data entries for transmission.
[0020] See Figure 2 From top to bottom, arrows indicate the direction of message transmission over time. The on-chip network used in this embodiment includes: a request channel (REQ), a response channel (RSP), and a data channel (DAT). When a requesting node initiates a point-to-point write transmission to a home node, it first sends a write request (REQ.WrReq) to the home node via the request channel. The home node then sends a response message (RSP.WrReceipt) to the requesting node via the response channel. Finally, the requesting node sends the write data to the home node (DAT.WrData).
[0021] The home node's receiving resources include request entries and a data buffer. Request entries are used to track and control the entire lifecycle of a transaction, and the number of request entries determines the maximum number of write requests the home node can handle simultaneously. The data buffer is used to store the read / write data accompanying the write request (in the scenario described in the embodiments of this disclosure, the home node's data buffer is used to store write data).
[0022] See Figure 3 When a home node receives a write request, if it doesn't have enough request entries to process it, it will initiate a retransmission process: the home node returns a retransmission response message (RSP.Retry) to the requesting node, and the requesting node will pause the transaction upon receiving it. Only when the home node has enough request entries to process the write request will it reserve dedicated request entries and return an arbitration response message (RSP.Grant) to the requesting node. Only then can the requesting node re-initiate the request with a retransmission permission flag (credit) and complete the transaction corresponding to the write request normally.
[0023] Furthermore, for point-to-point transaction flows that require order preservation, the processing flow is as follows: The PCIe device 0, acting as the sender, initiates a burst write request to the requesting node (RN). The burst write request contains parameters indicating transport attributes, including at least: the starting address (Addr), the number of packets (Length), and the size of a single packet (Size). Then, the PCIe device sends the write data related to the total data volume to the requesting node.
[0024] Upon receiving a burst write request, the requesting node is configured to fragment the burst write request into several smaller write transactions, which are then sent sequentially to the target node. See also... Figure 4 Red indicates continuously sent request messages, blue indicates continuously returned response messages, and green indicates continuously transmitted write data (e.g., 64B data).
[0025] It should be noted that in the on-chip network architecture of this embodiment, the maximum data transfer volume in a single transaction between the requesting node and the home node is set to 64 bytes. This setting is mainly based on the common server cacheline size (usually 64 bytes) in chip design and the stipulations of the consistency protocol. However, due to the segmentation of data transmission in the on-chip network, the transmission process still follows the aforementioned protocol, that is, the burst transmission of large data volumes is divided into multiple sub-transactions of 64 bytes each (two transmissions on a 32-byte transmission basis) for processing.
[0026] In the above point-to-point transmission mechanism, in order to achieve high-bandwidth transmission while simultaneously satisfying the ordering requirements of transactions, the system must be based on the following logic: 1. The traversal of the on-chip network itself must guarantee the transmission order, that is, the write request sent by the requesting node first (e.g., REQ.WrReq0) must arrive at the home node before the write request sent later (e.g., REQ.WrReq1), and the message sent first will not be overtaken by the message sent later on the transmission path.
[0027] 2. Home nodes must ensure that requests are forwarded downstream in the order they are received, and these requests typically use the same transaction ID.
[0028] 3. The transmission of requests between the home node and the destination PCIe device must be guaranteed to be out of order, that is, the first request will not be overtaken by the later request.
[0029] 4. The PCIe device acting as the receiving end must be able to process requests with the same transaction ID from the home node in sequence.
[0030] Based on the aforementioned prerequisites, the requesting node is allowed to continuously send requests to the home node. That is, subsequent write requests (e.g., REQ.WrReq1) do not need to wait for a response message (e.g., RSP.WrRceipt0) to the preceding write request (e.g., REQ.WrReq0) before being sent. Instead, multiple requests can be sent continuously, enabling the requesting node and home node to achieve the ideal write data bandwidth (i.e., continuous transmission of write data).
[0031] If any of the above logics is not true (for example, allowing a later write request REQ.WrReq1 to arrive at the home node before an earlier write request REQ.WrReq0), the requesting node will be unable to send requests continuously, leading to a significant drop in transmission bandwidth. More seriously, if out-of-order requests are received (for example, the home node receives the later write request REQ.WrReq1 before the home node), it will result in the inability to process data correctly in strictly ordered point-to-point transactions, and may even cause a system deadlock under certain contention scenarios.
[0032] See Figure 5 The following example describes the process after a retry occurs in point-to-point transmission, and then analyzes its impact on performance and the challenges it poses to the design.
[0033] The requesting node sends the first write request WrReq0 to the home node, and the first write request WrReq0 is received by the home node, thus completing the process normally.
[0034] When the second write request WrReq1 arrives at the home node, the home node's request table is already full and cannot receive it, so it returns a retransmission response message Retry1 for the second write request.
[0035] The first write request WrReq1, the second write request WrReq2, and the third write request WrReq3 all have a requirement to maintain order. Even if the second write request WrReq2 and the third write request WrReq3 arrive at the home node with sufficient resources, the second write request WrReq2 and the third write request WrReq3 must still be retransmitted.
[0036] When a request entry is released by the home node, it returns the arbitration response message Grant1 for the first write request, Grant2 for the second write request, and Grant3 for the third write request in turn for the retransmitted first write request WrReq1, second write request WrReq2, and third write request WrReq3.
[0037] Each time the requesting node receives an arbitration response message, it sends a retransmission request to the home node in sequence: first write request WrReq1, second write request WrReq2, and third write request WrReq3.
[0038] The home node returns a response message WrReceipt1 for the first write request, a response message WrReceipt2 for the second write request, and a response message WrReceipt3 for the third write request to the requesting node one by one.
[0039] The requesting node sends write data WrData1, write data WrData2, and write data WrData3 to the home node in sequence.
[0040] However, when retransmissions occur in the aforementioned point-to-point transmission, the data transmission performance of the on-chip network drops significantly.
[0041] See Figure 5 The home node may be in a non-full state most of the time (i.e., it can handle the transaction corresponding to the write request), and only occasionally will the request table be full. If it happens to encounter a large series of transactions from the requesting node when the request table is full, the home node needs to retransmit all subsequent order-keeping requests from the requesting node, causing the efficiency of this transaction chain to suddenly and significantly decrease.
[0042] When the home node is already full of request entries, it will cause further congestion on the request link between the requesting node and the home node. For example, if the first request of the requesting node has been retransmitted, and there are still 63 requests to be retransmitted, then all 63 requests will definitely be retransmitted, but these requests are already on the link. During this time, even if the home node can receive new requests, these requests that are about to be retransmitted will occupy the link for a period of time, affecting other requests from entering the home node.
[0043] Retransmissions generate a large number of response messages. Each retransmitted request will inevitably generate two response messages: a retransmission response message RSP.retry and an arbitration response message RSP.Grant. This causes the response channel to be occupied for a long time, affecting the home node's ability to return other normal response messages, thereby reducing the home node's own efficiency in processing transactions.
[0044] In addition, the design of retransmission handling by the requesting node and the home node is quite challenging.
[0045] In existing on-chip network communication architectures, home nodes often require additional hardware costs to achieve accurate retransmission of ordered transaction chains.
[0046] Specifically, on-chip network systems typically contain multiple requesting nodes, and the ordering requirement for transactions usually only constrains sequences of transactions from the same source (i.e., from the same requesting node and in the same direction). Transactions from different sources usually do not have an ordering requirement. Therefore, in order to maintain this priority ordering relationship, the home node must have the ability to accurately distinguish the source of each transaction.
[0047] To address this, existing home nodes typically need to be configured with retransmission trackers or similar logging entries to record in real time which transaction chains from which specific sources are currently in a retransmission state. The purpose of this design is to prevent other unrelated transaction chains (e.g., from other RNs) from being forced into retransmission when a particular event chain is in a retransmission state. However, maintaining such a complex tracking mechanism not only increases circuit area and power consumption but also significantly increases the complexity of the logic design.
[0048] See Figures 6 to 8 The retransmission tracing unit of a node typically has complex control logic. Internally, the retransmission tracing unit maintains multiple tracing entries, and the operation cycle of each entry includes three phases: registration, matching, and deregistration.
[0049] Specifically, the workflow is as follows: When a home node performs a retransmission operation on a new transaction chain, it extracts the identifier (ID) of that transaction chain and registers it in an idle entry in the retransmission tracking unit. Then, for each subsequent request arriving at the home node, the system matches it one by one with all registered valid entries in the retransmission tracking unit; if a match is found, it indicates that the request belongs to the transaction chain currently undergoing retransmission, and other subsequent requests arriving at the home node will soon be retransmitted.
[0050] The cancellation mechanism for the above entries is typically based on the detection of letters of credit. When the retransmission tracking unit receives the first request with a letter of credit belonging to the transaction chain (the request with a letter of credit indicates that the retransmitted request has been authorized and that the current transmission is guaranteed to be received), the system determines that the retransmission blocking state of the transaction chain has ended, and then performs a cancellation operation on the corresponding entry to release the request entry.
[0051] However, the above mechanism faces a trade-off between request entries and performance in practical design. At this time, the on-chip network may simultaneously include a large number of guaranteed transaction chains, and the entry capacity (i.e., the number of entries) of the retransmission tracking unit becomes a key design consideration: on the one hand, if the number of configured entries is too large, it will directly lead to a significant increase in the total chip size (area overhead); on the other hand, if the number of configured entries is too small, when the concurrent retransmission transaction chains exceed the entry capacity, new requests will face the problem of being neither received nor registered as needing to enter the retransmission process, thus being forced to remain on the transmission path, directly causing severe queue congestion, and thus reducing the overall throughput performance of the system.
[0052] In on-chip network communication protocols, to meet the ordering requirement, requesting nodes must maintain the order of transaction chains. When a request in this transaction chain encounters congestion and is triggered to be retransmitted, the requesting node must strictly follow the order and send the requests in sequence, starting from the first retransmitted request.
[0053] In a simple scenario where the requesting node receives the retransmission instruction only after it has sent all requests in the transaction chain, determining the starting point for retransmitting the request is relatively easy. However, if the requesting node receives a retransmission response message RSP.retry and an arbitration response message RSP.Grant during the transmission of the original request sequence, severe out-of-order problems may occur due to internal scheduling and process competition for interrupted transmission.
[0054] Combination Figure 9 The specific scenario shown illustrates the aforementioned out-of-order risk. Assume the requesting node needs to send four write requests in sequence (denoted as the first write request WrReq0, the second write request WrReq1, the third write request WrReq2, and the fourth write request WrReq3): At time T5, the home node successfully received and processed the first write request WrReq0 of the transaction chain.
[0055] At time T8, the home node, having filled its internal request table, registered a RetryTrackerEntry for the event chain and began retransmitting subsequent upstream same-origin requests.
[0056] At time T0, the requesting node publishes its third write request, WrReq2. Simultaneously, a subsequent fourth write request, WrReq3, is awakened and enters the queue for arbitration. However, at this moment, although the fourth write request WrReq3 meets the scheduling conditions, it fails to immediately obtain a queue due to the arbitration mechanism, such as polling.
[0057] At time T1, the requesting node receives a Grant response message for the rejected request. Requesting arbitration, the requesting node begins retransmitting the first retransmitted request (i.e., the second write request WrReq1_credit carrying the letter of credit). At this point, the second write request WrReq1_credit carrying the letter of credit is arbitrated and sent.
[0058] At time T2, the fourth write request WrReq3, which has participated in scheduling but has not yet obtained a request entry, is learned. At this time, the request entry is obtained and sent by the requesting node.
[0059] At time T9, the home node receives the first second write request, WrReq1_credit, carrying a letter of credit. According to the protocol, the home node determines that the retransmission blocking for this transaction chain has been lifted and therefore cancels the corresponding retransmission tracking entry.
[0060] At time T10, the home node receives the fourth write request WrReq3. At this time, since the retransmission tracking entry has been deregistered (at time T9) and the home node happens to have an idle request entry, the home node mistakenly receives and processes the fourth write request WrReq3 directly.
[0061] At time T10, the home node received the fourth write request WrReq3, which had a later sequence number. However, the earlier third write request WrReq2 (which was waiting for retransmission at that time) had not yet been received by the home node as it carried a letter of credit. This resulted in the home node processing write requests in the following order: (first write request WrReq0 -> second write request WrReq1 -> fourth write request WrReq3 -> third write request WrReq2), which did not conform to the preset order, causing data out-of-order processing.
[0062] To avoid such out-of-order delivery, requesting nodes are typically instructed to suppress retransmission requests carrying letters of credit upon receiving the arbitration response message. Retransmission only begins after all original requests in the transaction chain have been sent and confirmed for retransmission. This approach reduces transmission efficiency. Alternatively, requesting nodes can pause sending any unsent original new requests upon receiving the arbitration response message. However, this logic is extremely difficult to control accurately in complex simulations and can easily lead to out-of-order write requests.
[0063] This disclosure provides a data transmission method applied to point-to-point communication in a PCIe on-chip network. In this embodiment, a requesting node sends a write request to a home node. The write request includes indication information indicating the total amount of write data corresponding to this data transmission. Based on the current data buffer state, the home node returns at least one write request receive response message to the requesting node, indicating the amount of data allowed to be sent by the home node. Based on the received write request receive response message and the amount of data allowed to be sent by the home node, the requesting node sends the corresponding write data to the home node. This disclosure enables the requesting node to interact with the entire transmission data channel of the home node through a single message, avoiding the need to break down a large data transmission task into multiple independent small write requests, thereby significantly reducing the number of request messages generated in the on-chip network and reducing bandwidth consumption for requests.
[0064] The on-chip network of this disclosure includes: a requesting node and a home node, see [link to relevant documentation]. Figure 10 The method includes: Step S1: The requesting node sends a write request to the home node. The write request contains indication information indicating the total amount of data to be written for this data transfer.
[0065] Step S2: If the home node has a request entry to process the write request, the home node returns at least one write request receive response message to the requesting node based on the current data buffer state. The write request receive response message indicates the amount of data that the home node is allowed to send.
[0066] Step S3: The requesting node sends the corresponding write data to the home node based on the received write request response message and the amount of data allowed to be sent by the home node.
[0067] The embodiments disclosed herein enable the requesting node to access the entire data transmission channel of the node through a single message interaction, avoiding the need to break down a large data transmission task into multiple independent lowercase requests for separate transmission. This significantly reduces the number of request messages generated in the on-chip network and lowers the bandwidth consumption of requests.
[0068] In some specific implementations of the embodiments of this disclosure, the indication information includes: the number of data packets and the size of a single data packet, and the total amount of data written is determined based on the number of data packets and the size of a single data packet.
[0069] In this embodiment of the disclosure, the requesting node obtains the total write data volume based on the number of data packets and the size of a single data packet. By including the total write data volume in a single write request message, the number of request messages is effectively reduced, and the load rate of the on-chip network request channel (REQ channel) is significantly reduced.
[0070] In some specific implementations of the embodiments of this disclosure, after the home node receives a write request, it returns a write request response message in two modes.
[0071] In the first mode, the home node returns a write request receive response message to the requesting node for each write data packet that is allowed to be received in the write request. The write request receive response message indicates to the home node that the requesting node is allowed to send the corresponding write data packet.
[0072] The second mode is that the home node returns a write request receive response message to the requesting node in response to the write request. The write request receive response message indicates the number of write data packets that the home node allows the requesting node to send.
[0073] Specifically, in the first mode, the home node returns a receive response message for each write request to be received in sequence, and the number of receive response messages for each write request corresponds to the number of write requests.
[0074] See Figure 11 The home node adopts the first mode and is in an idle state.
[0075] The requesting node sends a write request REQ.WrReq to the home node. The write request REQ.WrReq includes indication information, namely the number of packets (length=8) and the size of a single packet (Size=64B).
[0076] The home node calculates the total data volume as 8 × 64 B based on the inferred number of data packets (length=8) and the size of a single data packet (Size=64B). It then returns write request receive responses RSP.WrReicpt0 to RSP.WrReicpt7 sequentially. The requesting node, upon receiving each write request receive response message, then sequentially sends the corresponding write data DAT.WrData0 to DAT.WrData7.
[0077] See Figure 12 The home node adopts the second mode and is in a busy state.
[0078] The requesting node sends a write request REQ.WrReq to the home node. The write request REQ.WrReq includes indication information, namely the number of packets (length=8) and the size of a single packet (Size=64B).
[0079] The home node sequentially returns the first receive response message from RSP.WrReicpt0 to RSP.WrReicpt3. After receiving each write request receive response message, the requesting node sequentially sends the corresponding write data from DAT.WrData0 to DAT.WrData3. After sending the fourth write request receive response message (RSP.WrReicpt3), the home node cannot allocate a new data buffer due to buffer limitations, and therefore will not retransmit. The home node waits for the data buffer to be released before returning write request receive response messages from RSP.WrReicpt4 to RSP.WrReicpt7. After receiving each write request receive response message, the requesting node sequentially sends the corresponding write data from DAT.WrData4 to DAT.WrData7.
[0080] Specifically, in the second mode, the home node dynamically replies to the write request with a receive response message, and the number of receive response messages is not related to the number of write requests.
[0081] See Figure 13 The home node adopts the second mode and is in an idle state.
[0082] The requesting node sends a write request REQ.WrReq to the home node. The write request REQ.WrReq includes indication information, namely the number of packets (length=8) and the size of a single packet (Size=64B).
[0083] The home node calculates the total data volume as 8 × 64 bytes based on the inferred number of data packets (length=8) and the size of a single data packet (Size=64B). It then returns a receive response message RSP.WrReicpt0, indicating how many data packets the requesting node can send to the home node at this time. In the example, because the home node's data buffer is free, it allocates a data buffer for all the requested data at once, instructing the requesting node to send all data (DAT.WrData0 to DAT.WrData7) to the home node all at once.
[0084] See Figure 14 The home node adopts the second mode and is in a busy state.
[0085] The requesting node sends a write request REQ.WrReq to the home node. The write request REQ.WrReq includes indication information, namely the number of packets (length=8) and the size of a single packet (Size=64B).
[0086] The home node calculates the total data volume as 8 × 64 bytes based on the inferred number of data packets (length = 8) and the size of a single data packet (Size = 64 bytes). However, the home node is in a busy state and can only receive two write data packets. The home node returns a write request receive response message RSP.WrReicpt0 to the requesting node, indicating that the requesting node can now send two data packets to the home node. The requesting node sends the data packets DAT.WrData0 and DAT.WrData1 to the home node.
[0087] The home node then returns a write request receive response message RSP.WrReicpt0 to the requesting node, indicating that the requesting node can now send a data packet to the home node. The requesting node sends the data DAT.WrData2 to the home node.
[0088] The home node's data buffer is largely freed, and it then returns a write request receive response message RSP.WrReicpt0 to the requesting node, indicating that the requesting node can now send the remaining five data packets to the home node. The requesting node sends data DAT.WrData3 to DAT.WrData7 to the home node.
[0089] In a specific implementation of this disclosure, the home node dynamically sends multiple write request receive response messages based on the release status of the data buffer, indicating the number of write data packets allowed to be sent in batches. This disclosure enables the home node to flexibly return multiple response messages based on the real-time release status of its internal data buffer, dynamically instructing the requesting node to send partial write data in stages. This disclosure avoids transmission blocking caused by waiting for the full data buffer to expire or performance drops caused by triggering retransmission mechanisms, ensuring that long bursts of write transactions can continue even under network congestion, thereby significantly improving the throughput and data transmission efficiency of the on-chip network under high load scenarios.
[0090] In some specific implementations of the embodiments disclosed herein, see [link to relevant documentation]. Figure 15 The method also includes: Step S4: If the home node has no request entry to process the write request, the home node returns a retransmission response message to the requesting node.
[0091] Step S5: After receiving the retransmission response, the requesting node suspends the transaction processing of the write request and waits to receive the arbitration response message.
[0092] Step S6: If the home node has a request entry to process the write request, the home node sends an arbitration response message to the requesting node. The arbitration response message includes the letter of credit.
[0093] Step S7: After receiving the arbitration response message, the requesting node resends the write request to the home node. The write request includes indication information for the total amount of write data corresponding to this data transmission and a letter of credit.
[0094] See Figure 16 When the home node has no request entry and therefore cannot receive a write request, it only needs to return a retransmission response to the requesting node once. After the home node releases the request entry, it returns an arbitration response message. Then, the requesting node resends a write request with indication information and a letter of credit to the home node. The indication information is used to indicate the total amount of write data corresponding to this data transmission.
[0095] In this embodiment, whether the home node can receive a write request depends on whether it has at least one free request entry. If a request entry is available, the write request can be processed; otherwise, it cannot. Upon receiving a retransmission response, the requesting node suspends transaction processing for the write request and waits to receive an arbitration response message. In this embodiment, once the home node has a request entry available to process the write request, it sends an arbitration response message to the requesting node. The home node reserves a request entry for write requests entering the retransmission process. The arbitration response message includes a letter of credit. When the requesting node receives the arbitration response message and retransmits the write request, it includes the letter of credit, thus successfully entering the request entry reserved by the home node for that write request. If the letter of credit is not included, the retransmitted write request may still be retransmitted, which does not conform to the expected processing flow.
[0096] This disclosure also provides a data transmission method applied to a home node in PCIe point-to-point communication in a network-on-chip (PCIe) network, wherein the PCIe network includes a requesting node and a home node.
[0097] See Figure 17 The method includes: Step N1: Receive the write request sent by the requesting node. The write request contains indication information indicating the total amount of write data corresponding to this data transmission.
[0098] Step N2: If the home node has a request entry to process the write request, based on the current data buffer state, it returns at least one write request receive response message to the requesting node. The write request receive response message indicates the amount of data that the home node is allowed to send.
[0099] Step N3: The receiving node sends the write data based on the write request's receive response message. The write data corresponds to the data volume information.
[0100] The embodiments disclosed herein enable the requesting node to access the entire data transmission channel of the node through a single message interaction, avoiding the need to break down a large data transmission task into multiple independent lowercase requests for separate transmission. This significantly reduces the number of request messages generated in the on-chip network and lowers the bandwidth consumption of requests.
[0101] See Figure 18 The method of this disclosure embodiment also includes: Step N4: If no write request is processed in the request table, return a retransmission response message to the requesting node.
[0102] Step N5: When a write request is processed for a request entry, an arbitration response message is sent to the requesting node. The arbitration response message includes the letter of credit.
[0103] Step N6: The receiving and processing node resends the write request after receiving the arbitration response message. The write request contains indication information for the total amount of write data corresponding to this data transmission and a letter of credit.
[0104] This disclosure also provides a data transmission method applied to a request node in PCIe point-to-point communication in a network-on-chip (PCIe) network, wherein the PCIe network includes a request node and a home node.
[0105] See Figure 19 The method includes: Step M1: Send a write request to the home node. The write request contains indication information indicating the total amount of data to be written for this data transfer.
[0106] Step M2: If the home node has a request entry to process the write request, receive at least one write request receive response message returned by the home node based on the write request. The write request receive response message is determined by the home node based on the current data buffer state. The write request receive response message indicates the amount of data that the home node is allowed to send.
[0107] Step M3: Based on the received response message of the write request, and according to the amount of data allowed to be sent by the home node, send the corresponding write data to the home node.
[0108] The embodiments disclosed herein enable the requesting node to access the entire data transmission channel of the node through a single message interaction, avoiding the need to break down a large data transmission task into multiple independent lowercase requests for separate transmission. This significantly reduces the number of request messages generated in the on-chip network and lowers the bandwidth consumption of requests.
[0109] See Figure 20 This disclosure also provides an on-chip network system, which includes a requesting node and a home node.
[0110] The requesting node sends a write request to the home node. The write request contains information indicating the total amount of data to be written for this data transfer.
[0111] If the home node has a request entry to process a write request, the home node returns at least one write request receive response message to the requesting node based on the current data buffer state. The write request receive response message indicates the amount of data that the home node is allowed to send.
[0112] Based on the received write request response message and the amount of data allowed to be sent by the home node, the requesting node sends the corresponding write data to the home node.
[0113] The embodiments disclosed herein enable the requesting node to access the entire data transmission channel of the node through a single message interaction, avoiding the need to break down a large data transmission task into multiple independent lowercase requests for separate transmission. This significantly reduces the number of request messages generated in the on-chip network and lowers the bandwidth consumption of requests.
[0114] It should be understood that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the method embodiments, since they are basically similar to the methods described in the apparatus and system embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions of other embodiments.
[0115] It should be understood that the foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0116] It should be understood that the use of a singular form to describe an element or to show only one element in the accompanying drawings does not imply that the number of such element is limited to one. Furthermore, modules or elements described or shown as separate herein may be combined into a single module or element, and modules or elements described or shown as single herein may be broken down into multiple modules or elements.
[0117] It should also be understood that the terminology and expressions used herein are for descriptive purposes only, and one or more embodiments described herein should not be limited to these terms and expressions. The use of these terms and expressions does not exclude any illustrative and descriptive equivalent features (or parts thereof), and it should be recognized that various modifications that may exist should also be included within the scope of the claims. Other modifications, variations, and substitutions may also exist. Accordingly, the claims should be considered to cover all such equivalents.
Claims
1. A data transmission method applied to PCIe point-to-point communication in a network-on-chip (PCIe) system, wherein the PCIe system comprises: The method for requesting nodes and home nodes includes: The requesting node sends a write request to the home node, and the write request includes indication information indicating the total amount of write data corresponding to this data transmission. If the home node has a request entry to process the write request, the home node returns at least one write request receive response message to the requesting node based on the current data buffer state and the write request receive response message, which indicates the amount of data that the home node is allowed to send. The requesting node sends the corresponding write data to the home node based on the received response message of the write request and the amount of data allowed to be sent by the home node.
2. The method according to claim 1, wherein, The indication information includes: the number of data packets and the size of a single data packet, and the total amount of data written is determined based on the number of data packets and the size of a single data packet.
3. The method according to claim 2, wherein, The home node, based on the current data buffer state, returns at least one write request receive response message to the requesting node based on the write request, including: Based on the current data buffer state, the home node returns a write request receive response message to the requesting node for each allowed write data packet of the write request. The write request receive response message indicates that the home node allows the requesting node to send the corresponding write data packet; and / or, Based on the current data buffer state, the home node returns a write request receive response message to the requesting node in response to the write request. The write request receive response message indicates the number of write data packets that the home node allows the requesting node to send.
4. The method according to claim 3, wherein, The home node returns a write request receive response message in response to the write request. The write request receive response message indicates the number of write packets that the home node is allowed to send, including: The home node dynamically sends multiple write request receive response messages based on the current data buffer release status, indicating the number of write data packets allowed to be sent in batches.
5. The method according to claim 1, wherein, The method further includes: If the home node has no request entry to process the write request, the home node returns a retransmission response message to the requesting node; After receiving the retransmission response, the requesting node suspends the transaction processing of the write request and waits to receive the arbitration response message. If the home node has a request entry to process the write request, the home node sends the arbitration response message to the requesting node, the arbitration response message including the letter of credit; After receiving the arbitration response message, the requesting node resends the write request to the home node. The write request includes indication information for the total amount of data to be written corresponding to this data transmission, as well as the letter of credit.
6. The method according to claim 5, wherein, The home node returns a retransmission response to the requesting node.
7. A data transmission method applied to a home node in PCIe point-to-point communication on a network-on-chip (PCIe), wherein the PCIe comprises: The method for requesting nodes and home nodes includes: Receive a write request sent by the requesting node, wherein the write request contains indication information for indicating the total amount of write data corresponding to this data transmission; If the home node has a request entry to process the write request, it returns at least one write request receive response message to the requesting node based on the current data buffer state, according to the write request. The write request receive response message indicates the amount of data that the home node is allowed to send. The requesting node receives the write data sent by the response message based on the write request, and the write data corresponds to the data volume information.
8. The method according to claim 7, wherein, The method further includes: If no request entry processes the write request, a retransmission response message is returned to the requesting node; When a request entry processes the write request, an arbitration response message is sent to the requesting node, the arbitration response message including the letter of credit; The process receives and processes the write request resent by the requesting node after receiving the arbitration response message. The write request includes indication information for the total amount of write data corresponding to this data transmission and the letter of credit.
9. A data transmission method applied to a requesting node in PCIe point-to-point communication on a network-on-chip (PCIe), wherein the PCIe comprises: The method for requesting nodes and home nodes includes: Send a write request to the home node, the write request containing indication information indicating the total amount of data to be written for this data transmission; If the home node has a request entry to process the write request, it receives at least one write request receive response message returned by the home node based on the write request. The write request receive response message is determined by the home node based on the current data buffer state. The write request receive response message indicates the amount of data that the home node is allowed to send. Based on the received response message of the write request, and based on the amount of data that the home node is allowed to send, the corresponding write data is sent to the home node.
10. An on-chip network system, the on-chip network comprising: Request node and home node, The requesting node sends a write request to the home node, and the write request includes indication information indicating the total amount of write data corresponding to this data transmission. If the home node has a request entry to process the write request, the home node returns at least one write request receive response message to the requesting node based on the current data buffer state and the write request receive response message, which indicates the amount of data that the home node is allowed to send. The requesting node sends the corresponding write data to the home node based on the received response message of the write request and the amount of data allowed to be sent by the home node.