Data sending method, device and chip

Abstract

The application provides a data sending method and device and a chip, and relates to the technical field of communication. Firstly, real-time credit update information from a link layer is captured and analyzed to obtain a current real-time credit value; then, when a first access request is received, the real-time credit value is compared with a preset threshold value, and the state of the current link is determined according to the comparison result; the first access request is used to represent that an adaptive controller is in a current state without an ongoing merging batch, and a first data request received by a transaction buffer; when in an idle state, the current received data request is immediately packaged and sent; when in a congestion state, a timing window is started, and the data requests that can be merged are collected in the timing window, and the collected data requests are packaged and sent when the timing window is timed out or the number of the collected data requests reaches a set value. The scheme provided by the application has the advantages of low delay, high bandwidth utilization and strong adaptive capacity.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a data transmission method, apparatus, and chip. Background Technology

[0002] In high-speed interconnect protocols (such as CXL), in order to improve link utilization, a merging window is usually set up at the transaction layer to merge multiple small data requests into a large data frame (such as 256B Flit) before sending.

[0003] In existing technologies, a merging and sending mechanism based on a fixed timer is typically used. That is, when the first data packet arrives, a timer of a preset duration is started, and the system continues to wait for subsequent data packets until the timer expires. After the timer expires, the collected data packets are packaged and sent.

[0004] However, this fixed timer mechanism has the following drawbacks: First, unnecessary delays in low-load scenarios. Fixed timers cannot perceive the actual receiving capacity of the peer on the link. Even when the link is completely idle and the peer's credit is extremely high, the controller will still enforce a fixed waiting time, causing sporadic memory access requests to have artificial delays before being sent, thus compromising the system's low-latency performance requirements.

[0005] Second, bandwidth utilization fluctuates under high load scenarios. Under high load and link congestion, the fixed timer may time out and trigger transmission before collecting enough data requests, resulting in incomplete data frames. This not only wastes physical bandwidth but also increases pressure on the peer's buffer, inducing link layer retransmissions and causing drastic fluctuations in effective throughput.

[0006] Third, the system lacks dynamic adaptive capabilities. The parameters of fixed timers are usually set during initialization and cannot be dynamically adjusted according to the traffic characteristics during runtime, resulting in highly unstable system performance under different task loads.

[0007] Therefore, existing merging and sending mechanisms suffer from high latency, low bandwidth utilization, and lack of adaptability due to fixed merging windows. Summary of the Invention

[0008] The purpose of this application is to provide a data transmission method, apparatus and chip to solve the problems of high latency, low bandwidth utilization and lack of adaptive capability caused by fixed merging windows in the prior art.

[0009] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a data transmission method, the data transmission method comprising: Real-time capture and parsing of credit score update information from the link layer to obtain the current real-time credit score value; When the first access request is received, the real-time credit score value is compared with a preset threshold, and the current link status is determined based on the comparison result; wherein, the link status includes idle state and congestion state, and the first access request is used to characterize the first data request received by the transaction buffer when the adaptive controller is in a state where there is no ongoing merging batch; When in an idle state, immediately package and send the currently received data request; When in a congested state, a timing window is started, during which data requests that can be merged are collected, and when the timing window times out or the number of collected data requests reaches a set value, the collected data requests are packaged and sent.

[0010] Optionally, when in a congested state, the steps to start the timing window include: When in a congested state, the duration of the timing window is dynamically configured based on the real-time credit score value, wherein the duration of the timing window is negatively correlated with the real-time credit score value.

[0011] Optionally, the congestion state includes a first congestion state and a second congestion state, wherein the congestion level of the first congestion state is less than that of the second congestion state; the step of dynamically configuring the duration of the timing window based on the real-time credit score includes: When in the first congestion state, the sensitivity of the duration of the timing window to changes in the credit score value is the first sensitivity. When in the second congestion state, the sensitivity of the duration of the timing window to changes in the credit score value is the second sensitivity. The second sensitivity is greater than the first sensitivity.

[0012] Optionally, the congestion state includes a first congestion state and a second congestion state, wherein the congestion level of the first congestion state is less than that of the second congestion state; when in a congestion state, the step of starting the timing window includes: When in the second congestion state, start the longest timer window; When in the first stage of congestion, determine the current link trend; When the current link approaches an idle state, shorten the duration of the timing window; When the current link tends to the second congestion state, extend the duration of the timing window.

[0013] Optionally, before the step of packaging and sending the collected data requests when the timeout window expires or the number of collected data requests reaches a set value, the method further includes: The set value is determined based on the relationship between the real-time credit score value, the preset value, and the set value.

[0014] Optionally, the step of immediately packaging and sending the currently received data request includes: Disable the start of the timer and directly trigger the packaging and sending of data requests.

[0015] Optionally, the mergeable data request is a data request that is adjacent to the address of the first access request or meets a preset merging condition.

[0016] Optionally, the steps of capturing and parsing credit score update information from the link layer in real time to obtain the current real-time credit score value include: The received CXL protocol update packets are parsed in real time, and the available credit limit corresponding to the CXL.cache and CXL.mem protocols is extracted. The available credit limit is used as the real-time credit limit value.

[0017] Secondly, embodiments of this application also provide a data transmission device, the data transmission device comprising: The credit rating monitoring module is used to capture and parse credit rating update information from the link layer in real time to obtain the current real-time credit rating value. A threshold comparator, coupled to the credit monitoring module, is used to compare the real-time credit score with a preset threshold and output the current link status signal based on the comparison result; wherein, the link status includes idle state and congestion state; A transaction buffer is used to receive and temporarily store data requests, and to generate a trigger signal when the first access request is received; the first access request is used to represent the first data request received when there is no ongoing merge batch. An adaptive controller, coupled to the threshold comparator and the transaction buffer respectively, is used to generate corresponding control commands based on the status signals of the link in response to the trigger signal; A dynamic timer, coupled to the adaptive controller, is used to receive the enable signal and window configuration parameters issued by the adaptive controller, perform timing operations, and feed back a timeout signal to the adaptive controller when the timing ends. A packaging and packaging unit is coupled to the adaptive controller and the transaction buffer respectively, and is used to receive data requests from the transaction buffer when triggered by the adaptive controller, and to package and send them. The adaptive controller is configured as follows: When the status signal of the link indicates an idle state, the encapsulator is controlled to immediately encapsulate and send the currently received data request; When the status signal of the link indicates a congestion state, the encapsulator is controlled to package and send the collected data requests when the sending conditions are met; the sending conditions include: receiving the timeout signal of the dynamic timer, or the number of data requests collected by the transaction buffer reaching a set value.

[0018] Thirdly, embodiments of this application also provide a chip that integrates the aforementioned data transmission device.

[0019] Compared with the prior art, the embodiments of this application have the following beneficial effects: This application provides a data transmission method, apparatus, and chip. First, it captures and parses credit rating update information from the link layer in real time to obtain the current real-time credit rating value. Then, when the first access request is received, the real-time credit rating value is compared with a preset threshold, and the current link status is determined based on the comparison result. The link status includes an idle state and a congested state. The first access request represents the first data request received by the transaction buffer when the adaptive controller is currently not in the process of merging batches. When in an idle state, the currently received data request is immediately packaged and sent. When in a congested state, a timing window is started, and mergeable data requests are collected within the timing window. When the timing window times out or the number of collected data requests reaches a set value, the collected data requests are packaged and sent.

[0020] This application introduces a credit score as a real-time feedback signal to achieve link-state-based judgment. Based on the link state, different data transmission strategies are executed, forming a dynamic adaptive mechanism. This allows the system to adjust its strategies in real time according to changes in link state, solving the problem that fixed parameters cannot adapt to changes in runtime traffic characteristics. Simultaneously, when the system is determined to be in an idle state, it immediately packages and sends data, completely eliminating unnecessary delays caused by fixed waiting under low load. When the system is determined to be in a congested state, it starts a timing window and collects mergeable data requests, ensuring that data is fully compacted before transmission during congestion. This avoids sending incomplete data frames due to premature timeouts, thus solving the problem of bandwidth waste under high load.

[0021] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 An exemplary flowchart of a data transmission method provided in an embodiment of this application.

[0024] Figure 2 This is a schematic diagram of a data transmission device provided in an embodiment of this application.

[0025] In the picture: 110 - Credit monitoring module; 120 - Threshold comparator; 130 - Adaptive controller; 140 - Dynamic timer; 150 - Transaction buffer; 160 - Packer. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0027] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0028] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] It should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0030] It is understood that in the following specific embodiments of this application, issues and sampling parameters are involved. When the various embodiments of this application are applied to specific products or technologies, relevant licenses or consents need to be obtained, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0031] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0032] As described in the background section, in traditional CXL or PCIe controller designs, a merging mechanism based on a static timer is typically used to improve link utilization. This involves setting a fixed merging window counter at the transaction layer. The counter starts when the first 64-byte packet arrives in the buffer.

[0033] Regardless of the current link congestion, the counter runs at a preset constant period. The logic continuously waits for packets from neighboring addresses until the counter countdown ends. Only when the counter reaches zero or the buffer is full will a Flit encapsulation be triggered and the packet sent to the physical layer.

[0034] For example, in the CXL 3.1 protocol, a 256B data packet (flit) can be divided into 14 data slots, each holding 16B of data. A typical 64B access request occupies 4 data slots. In other words, a large data packet can hold a maximum of 3.5 such access requests.

[0035] However, existing merging and sending mechanisms based on fixed timers have the following drawbacks: 1. Unnecessary latency in low-load scenarios Because the timer cannot sense the actual receiving capacity of the peer link, even in the ideal state where the link is completely idle and the peer's credit is extremely abundant, the controller will still force a fixed waiting period. This causes sporadic memory access requests initiated by the CPU to have an artificial delay before being sent, which disrupts the system's consistent access performance and fails to meet the high-performance server's requirement for extremely low latency.

[0036] 2. Bandwidth Inefficiency under High Load Scenarios In existing technologies, under high load and link congestion (i.e., when the remote credit is nearly exhausted), fixed timers may time out and trigger transmission before finding enough merging requests. This results in uncompacted fragmented packets in the 256B Flit mode of the physical layer, leading to an excessively high proportion of header and error correction code (FEC) usage and wasting valuable physical bandwidth. Simultaneously, blindly sending fragmented packets exacerbates the pressure on the remote buffer, inducing more link layer retransmissions and causing significant fluctuations in effective throughput (goodput).

[0037] 3. The system lacks dynamic adaptive capability (Lack of Elasticity) Existing technical solutions typically fix parameters during initialization, making dynamic adjustment impossible based on runtime traffic characteristics. This results in the fixed merging strategy failing to balance latency and bandwidth when the SoC (System on Chip) runtime environment switches from simple configuration tasks to complex AI training or large-scale memory copying tasks, leading to highly unstable system performance under different task loads.

[0038] In view of this, in order to solve the above problems, this application provides a data transmission method. For one implementation method, please refer to [link / reference]. Figure 1 The method includes: S102 captures and parses credit rating update information from the link layer in real time to obtain the current real-time credit rating value.

[0039] S104, when the first access request is received, the real-time credit score value is compared with the preset threshold, and the current link status is determined based on the comparison result; wherein, the link status includes idle status and congestion status, and the first access request is used to characterize the first data request received by the transaction buffer when the adaptive controller is in a state where there is no ongoing merging batch.

[0040] S106, when in an idle state, immediately package and send the currently received data request.

[0041] S108, when in a congested state, start a timing window, collect data requests that can be merged within the timing window, and when the timing window times out or the number of collected data requests reaches a set value, package and send the collected data requests.

[0042] Understandably, this application breaks through the limitations of traditional open-loop merging controllers by introducing a closed-loop feedback mechanism based on link-layer creditworthiness, establishing a real-time feedback loop from the physical link layer to the transaction layer. Specifically, this application uses the currently available receiving capability of the remote device, i.e., the creditworthiness value, as the direct basis for determining the local data packaging and transmission rhythm. This breaks the rigid constraint of the traditional open-loop timed merging mechanism, which forces waiting regardless of whether the link is idle, allowing data transmission behavior to adaptively adjust to changes in the real-time carrying capacity of the link.

[0043] Building upon this, the closed-loop feedback mechanism provided in this application significantly reduces memory access latency in low-load scenarios. Specifically, in existing technologies, due to the use of open-loop control with a fixed timer, even if the link is completely idle, the first data packet must wait for the timer to expire. In this application, after determining the current link state, the idle state and the congested state can be directly distinguished. When in the idle state, it indicates that a low-load scenario is in progress. In this state, the system immediately packages and sends the currently received data request, completely eliminating the unavoidable fixed waiting time in existing technologies.

[0044] For example, if the existing technology uses a fixed timer with a duration of 10 seconds, when the system receives a data request, regardless of the current link state, it needs to wait 10 seconds before packaging and sending the data request. This results in a prolonged memory access latency (i.e., a fixed 10 seconds) in low-load scenarios. In this application, however, the link state is determined first. Once it is determined that the link is in an idle state, the currently received data request is packaged and sent immediately without any delay, achieving low-latency transmission in low-load scenarios. In one implementation, when the link is determined to be in an idle state, the timer is prevented from starting, and the data request packaging and sending operation is directly triggered, thereby effectively reducing latency.

[0045] Based on this implementation, for latency-sensitive CPU read requests, the solution provided in this application can effectively reduce artificial latency of dozens of clock cycles, significantly improving the single-core execution efficiency of ARM servers under non-saturated load.

[0046] It should be noted that during data transmission in the CXL protocol, multiple small data requests are typically merged into a large Flit frame before being sent. However, the merging operation is not continuous, but rather performed cyclically in batches. Each batch includes the complete process of initiating waiting, collecting requests, and packaging and sending. After a batch is completed, the adaptive controller enters an idle state, meaning there is no merging batch currently in progress, and it waits for the next trigger signal.

[0047] Based on this, the so-called first access request in this application refers to the first data request received by the transaction buffer when the adaptive controller is in a state where there are no ongoing merge batches (i.e., the previous batch has ended and there are currently no requests waiting to be merged). Understandably, this request is not one that can be simply added to an existing batch, but rather a starting signal used to trigger a new round of merge decisions.

[0048] For example, suppose the adaptive controller has determined that the link is congested, is executing a merge batch, and has started a timing window, with three requests already waiting to be merged in the transaction buffer. At this point, a fourth request, Q1, arrives in the transaction buffer. Since the adaptive controller is explicitly in a state with an ongoing merge batch, this newly arrived request Q1 simply needs to be added to the existing batch to wait. It will not trigger any new link state determinations or policy adjustments; therefore, request Q1 can only be considered a normal request, not the first access request.

[0049] For example, suppose the adaptive controller has completed the previous batch of transmissions, the timer has been reset, the transaction buffer is empty, and the adaptive controller is in an idle state. At this time, a new request Q2 arrives at the transaction buffer. Since the adaptive controller is in a state where no merging batches are in progress, request Q2 will be considered the first access request. Its arrival will immediately trigger the adaptive controller to read the current real-time credit score value, compare it with a preset threshold, determine whether the link is idle or congested, and decide on subsequent operations accordingly.

[0050] Taking a real-world scenario as an example, when a server is running, the system has just completed a round of Flit transmission, and the transaction buffer has been cleared. At this time, the CPU initiates a 64B read request A. When request A arrives at the transaction buffer, since there are no ongoing merging batches, request A is identified as the first access request. The adaptive controller then reads the real-time credit score (assuming the current credit score is sufficient and the system is in an idle state), and decides not to start a timer, directly requesting A to be packaged and sent. After the transmission is completed, the device returns to an idle state. Subsequently, request B arrives. Since the adaptive controller is again in a state where there are no ongoing merging batches, request B will also become the first access request, triggering a new round of independent decision-making. If the current link state is determined to be congested, a timer is started, and during this period, mergeable data requests are collected. If request C arrives at this time, since the adaptive controller is in a state where there are ongoing merging batches, request C will be treated as a normal access request, rather than the first access request in this batch. Furthermore, the system determines whether request C can be merged with request B. If they can be merged, request B and request C will be packaged and sent when the timer window expires or the number of collected data requests reaches a set value. For example, if the timer window duration is set to 50 microseconds and the set value is 3, the request packaging and sending operation will only be triggered when the duration reaches 50 microseconds or when the number of mergeable requests reaches 3. For instance, if request B and request C can be merged, and subsequent arriving requests cannot be merged with them, then request B and request C will be packaged and sent when the timer window duration reaches 50 microseconds. Alternatively, when another request D arrives, and request D can be merged with request B, then even though the duration has not yet reached 50 microseconds, the number of mergeable requests has reached 3, so request B, request C, and request D will be packaged and sent.

[0051] It should be noted that the mergeable data request described in this application is a data request that is adjacent to the address of the first access request or meets the preset merging conditions.

[0052] Specifically, when accessing computer memory using the CXL protocol, each data request (i.e., access request) carries a destination address to tell the memory controller where to read or write data. If the current link is congested, a timing window is started to attempt to collect mergeable data requests within the window, package these requests into the same Flit and send them together to improve bandwidth utilization.

[0053] In the CXL protocol, a single Flit can carry data from multiple slots. If multiple requests access contiguous regions in memory, sending them within the same Flit allows the receiving end to process them sequentially, maximizing efficiency. Therefore, when determining whether data requests can be merged, it's crucial to check if the target addresses of subsequent requests are spatially contiguous or adjacent to the target address of the first request. For example, if request A is the first access request and requests to read 64 bytes of data starting at address 0x1000 (i.e., address range 0x1000 ~ 0x103F), and request B's address range is 0x1040 ~ 0x107F, then since this address is immediately adjacent to 0x103F and the addresses are contiguous, requests A and B can be merged into the same Flit. Similarly, if request C's address range is 0x1080 ~ 0x10BF, then request C's address is adjacent to request B, and requests A, B, and C can be merged. If the address of request D is 0x5000, then it is not adjacent to any of the previous request addresses and cannot be merged.

[0054] Meanwhile, different applications have different latency and bandwidth requirements. Some scenarios are bandwidth-sensitive and can accept merging requests within the same page; others may only want to merge strictly adjacent requests. Therefore, preset merging conditions can be set to further achieve flexible configuration of merging conditions. For example, these preset merging conditions include, but are not limited to, whether the addresses of subsequent requests and the first access request are in the same cache line, whether the addresses of subsequent requests and the first access request are in the same memory page, and whether the high N bits of the addresses of subsequent requests and the first access request are the same. It is understandable that as long as the subsequent request and the first access request meet either of the above two conditions, the two requests can be merged.

[0055] It should be noted that when judging the current link status, a higher real-time credit score indicates that the receiver is more idle, meaning the current link status is more idle. Therefore, this application can adopt multiple implementation methods, which are illustrated below: In one implementation, the real-time credit score is directly compared with a preset threshold.

[0056] For example, if the preset threshold is set to 20, then when the real-time credit score is greater than 20, it means that the current link is in an idle state; when the real-time credit score is less than 20, it means that the current link is in a congested state.

[0057] Furthermore, when in a congested state, the timing window can be set to either a fixed duration or a flexible configuration. For example, with a fixed duration, the window length can be set relatively long, such as 100 microseconds. Within this window, the system collects mergeable data requests until a timeout occurs or the number of mergeable requests reaches a set value. With a flexible configuration, the timing window can be dynamically adjusted based on the real-time credit score. For instance, a higher real-time credit score corresponds to a shorter timing window, showing a negative correlation between the two.

[0058] In another implementation, the congestion state includes a first congestion state and a second congestion state. That is, when setting the preset threshold, two thresholds are set: a high threshold TH_high and a low threshold TH_low. Based on these two thresholds, the current link state can be divided into three states. For example, if the high threshold TH_high = 70 and the low threshold TH_low = 30, then if the real-time credit score is below 30, it is determined to be in the second congestion state; when the real-time credit score is above 70, it is determined to be in the idle state; and when the real-time credit score is between 30 and 70, it is determined to be in the first congestion state.

[0059] Optionally, when in a congested state, the duration of the timing window is dynamically configured based on the real-time credit score value, wherein the duration of the timing window is negatively correlated with the real-time credit score value.

[0060] In short, the lower the real-time credit score, the more congested the receiver is, and the longer the timing window. Conversely, the higher the real-time credit score, the more relaxed the receiver is, and the shorter the timing window. For example, when the real-time credit score is only 10, it indicates that the receiver is extremely congested. In this case, the timing window will be set very long, such as 60 microseconds, to wait longer and collect as many mergeable requests as possible, allowing each Flit to pack more data requests and avoid wasting bandwidth. When the real-time credit score rises back to 40, although it is still congested, the congestion has eased, and the timing window will be shortened to 30 microseconds because it is no longer necessary to wait that long. When the credit score approaches 70, it is almost in an idle state, and the timing window is further shortened to 10 microseconds, allowing requests to be packed and sent quickly.

[0061] Secondly, the system's sensitivity to changes in credit score can vary depending on the level of congestion. Specifically, the second congestion state represents severe congestion, and the first congestion state represents mild congestion. In the first congestion state, the sensitivity of the timing window duration to changes in credit score is the first sensitivity; in the second congestion state, the sensitivity of the timing window duration to changes in credit score is the second sensitivity; and the second sensitivity is greater than the first sensitivity.

[0062] In this application, during severe congestion, the system is highly sensitive to changes in real-time credit score values; for every unit change in credit score, the timing window adjusts significantly. However, during mild congestion, the sensitivity is lower; for the same change in credit score, the window adjustment is much smaller. For example, in the second congestion state, if the real-time credit score increases from 5 to 10, the timing window may drop sharply from 80 microseconds to 40 microseconds, an adjustment of 40 microseconds. But in the first congestion state, if the real-time credit score increases from 40 to 45, the timing window may only decrease from 35 microseconds to 32 microseconds, an adjustment of only 3 microseconds.

[0063] This configuration ensures that during severe congestion, any mitigation signal receives a positive response, allowing the timing window to shorten rapidly in response to congestion changes; while during mild congestion, the system remains relatively calm, without overreacting to minor fluctuations, and focuses more on maintaining overall stability.

[0064] Furthermore, this application also provides an adjustment method based on trend judgment. Specifically, during the initiation of the timing window, when in a second congestion state, the timing window of the maximum length is initiated; when in a first congestion state, the current link trend is first determined, and then the duration of the timing window is dynamically adjusted based on the current link trend. Specifically, when the current link tends towards an idle state, the duration of the timing window is shortened; when the current link tends towards a second congestion state, the duration of the timing window is extended.

[0065] When there is severe congestion, the longest timing window (e.g., 80 microseconds) is activated directly to compact the data as much as possible. When there is mild congestion, the trend of link status changes is observed: if the credit score is increasing (e.g., changing from 35 to 50, approaching idle), the timing window length is proactively shortened to prepare for early packet transmission; if the credit score is decreasing (e.g., changing from 50 to 35, approaching severe congestion), the timing window length is proactively extended.

[0066] For example, if the current credit score is 40, and recent changes in credit scores (40, 43, 46) indicate the link is transitioning towards an idle state, the timing window is shortened from 30 microseconds to 20 microseconds. Conversely, if changes are observed (40, 37, 34), the link congestion is worsening, and the timing window is extended from 30 microseconds to 45 microseconds. This approach allows for proactive responses to future congestion levels, either by increasing the waiting time before congestion fully worsens or by shortening it as congestion is about to ease, thus achieving smoother adaptive control.

[0067] It is understandable that the link congestion state identification logic provided in this application has at least the following beneficial effects: 1. Maximizes effective bandwidth (Goodput) in high-congestion scenarios. The CXL3.1 physical layer uses a fixed 256B Flit encapsulation with constant protocol overhead (FEC / CRC / Header). Existing technologies may still send fragmented Flits containing only a single 64B data segment due to fixed timeouts during congestion. In this application, however, by dynamically setting the timing window length, the waiting window is extended under congestion conditions, forcing data compaction. By increasing the proportion of effective payload within a single Flit (from 75% to over 90%), this application significantly reduces the bandwidth occupied by the protocol header at the same physical bus frequency, thereby providing higher effective data throughput under heavy link pressure.

[0068] 2. Enhanced the determinism and stability of the system under complex loads. Existing technologies, with their indiscriminate transmission, can trigger frequent retransmissions at the link layer when the remote end's credit limit is exhausted. These retransmissions cause a sudden surge in bus traffic, resulting in significant performance fluctuations. This application achieves precise scheduling through real-time credit limit values. When a decrease in remote receiving capability is detected, the transmission pace is proactively slowed down and the single-input credit limit is increased, effectively avoiding link retry storms caused by buffer overflows or credit exhaustion. This allows the SoC to maintain a smoother performance curve when handling sudden high-volume loads such as AI training, enhancing QoS (Quality of Service) guarantees in multi-tenant environments.

[0069] 3. Reduced power consumption per unit of data transmission For transmitting the same amount of 64B data, this application requires fewer total Flits during congestion than existing technologies. By reducing the number of high-frequency switching transmissions of IDLE or low-load Flits at the physical layer, this application reduces the dynamic power consumption of the controller and physical link while completing the same workload, meeting the energy efficiency optimization requirements of high-performance server chips.

[0070] It should be noted that in this application, the set value can be a fixed value, such as a fixed value of 3 or 4; or it can be a dynamically adjustable value. When the set value is dynamically adjustable, the set value is associated with the real-time credit score value. Based on this, the set value can be determined based on the relationship between the real-time credit score value, the preset value, and the set value.

[0071] As one implementation method, there is a negative correlation between the credit score and the set value: the lower the credit score, the higher the set value; the higher the credit score, the lower the set value. Specifically, the lower the credit score (the busier the receiver), the more the system wants to send more data requests at once to conserve bandwidth, so the set value will be set higher; the higher the credit score (the receiver gradually becomes less busy), the more the system can accept sending fewer data requests, so the set value can be set lower.

[0072] Furthermore, the relationship between the preset values ​​and the set values ​​described in this application can be a linear relationship between the two, or a one-to-one correspondence between the real-time credit score values ​​and the set values, such as a correspondence table between real-time credit score values ​​and set values. For example, when the real-time credit score value is 0~10, the set value is 12; when the real-time credit score value is 11~30, the set value is 8; when the real-time credit score value is 31~60, the set value is 5; and when the real-time credit score value is 61~70, the set value is 3.

[0073] Furthermore, in this application, the dynamic adjustment of the set value and the dynamic adjustment of the timing window are two mechanisms that work in parallel and cooperate with each other. The sending trigger condition is either the timing window expires or the number of collections reaches the set value, whichever comes first.

[0074] For example, in one scenario, the current credit score is 15 (severe congestion), the timing window is set to 60 microseconds, and the setpoint is 8 requests. Suppose data requests arrive very frequently, and by the 30th microsecond after the timing window starts, the system has collected all 8 requests. Since the condition of reaching the set number of requests is met first, the system will immediately trigger packet transmission without waiting for the 60-microsecond timeout. This demonstrates a quantity-priority triggering logic.

[0075] In another scenario, the current credit score is 15, the timer window is set to 60 microseconds, and the set value is 8 requests. Assuming data requests arrive very sparsely, the system may only have collected 3 requests by the end of the 60-microsecond timer window. Since the timer window timeout condition is met first, the system will still trigger packet sending, sending the 3 collected requests to avoid indefinite waiting. This demonstrates the time-based fallback protection logic.

[0076] Based on the above implementation, this application also provides a data transmission device. Please refer to [link to relevant documentation]. Figure 2The data transmission device includes: The credit rating monitoring module 110 is used to capture and parse credit rating update information from the link layer in real time to obtain the current real-time credit rating value.

[0077] The threshold comparator 120, coupled to the credit rating monitoring module 110, is used to compare the real-time credit rating value with a preset threshold and output the current link status signal based on the comparison result; wherein, the link status includes idle status and congestion status.

[0078] Transaction buffer 150 is used to receive and temporarily store data requests, and to generate a trigger signal when the first access request is received; the first access request is used to characterize the first data request received when there is no ongoing merge batch.

[0079] The adaptive controller 130 is coupled to the threshold comparator 120 and the transaction buffer 150 respectively, and is used to respond to the trigger signal and generate corresponding control commands based on the status signal of the link.

[0080] The dynamic timer 140, coupled to the adaptive controller 130, is used to receive the enable signal and window configuration parameters issued by the adaptive controller 130, perform timing operations, and feed back a timeout signal to the adaptive controller 130 when the timing ends.

[0081] Encapsulator 160, coupled to both adaptive controller 130 and transaction buffer 150, is used to receive data requests from transaction buffer 150 upon triggering by adaptive controller 130, encapsulate and package them, and then send them. Adaptive controller 130 is configured as follows: When the link status signal indicates an idle state, the control encapsulator 160 immediately encapsulates and sends the currently received data request; When the link status signal indicates a congestion state, the encapsulator 160 is controlled to package and send the collected data requests when the sending conditions are met. The sending conditions include: receiving a timeout signal from the dynamic timer 140, or the number of data requests collected by the transaction buffer 150 reaching a set value.

[0082] It should be noted that in high-speed data transmission, traditional transmitting devices often employ a fixed waiting time strategy. This leads to unnecessary delays when the link is idle, and wastes bandwidth by sending incomplete data frames when the link is congested. The data transmitting device provided in this embodiment can adaptively adjust the transmitting strategy according to the actual processing capacity of the receiving end, thereby achieving a better balance between latency and bandwidth under different load conditions.

[0083] The functions of each module in the data transmission device provided in this application are described in detail below: The credit rating monitoring module 110 is coupled to the link layer interface. It should be noted that in the CXL protocol, the receiving end continuously sends messages containing credit update information (i.e., update Flit) through the link layer to inform the sending end of its currently available buffer capacity. The credit rating monitoring module 110 is used to parse the received CXL protocol update packets in real time and extract the available credit limits corresponding to the CXL.cache and CXL.mem protocols. This available credit limit is the real-time credit rating value described in this embodiment. Understandably, the credit rating monitoring module 110 continuously monitors the credit update information transmitted from the link layer interface and uses the parsed real-time credit rating value as the basis for subsequent decisions.

[0084] A threshold comparator 120 is coupled to the credit rating monitoring module 110. The threshold comparator 120 internally contains at least two programmable registers, designated as a first preset threshold and a second preset threshold, respectively. In practical applications, the threshold comparator 120 receives real-time credit rating values ​​from the credit rating monitoring module 110, quantizes and compares these values ​​with the two preset thresholds, and outputs a status signal for the current link based on the comparison result. Specifically, when the real-time credit rating value is greater than the first preset threshold, the status signal output by the threshold comparator 120 indicates that the link is in an idle state; when the real-time credit rating value is less than the first preset threshold, it indicates that the link is in a congested state. Furthermore, when the real-time credit rating value is less than the second preset threshold, the output status signal indicates that the link is in a second congested state; when the real-time credit rating value is greater than the second preset threshold, the output status signal indicates that the link is in a first congested state. Therefore, the threshold comparator 120 converts continuous credit rating values ​​into discrete link status levels, providing clear input for subsequent control decisions.

[0085] Transaction buffer 150 is used to receive and temporarily store data requests from the system bus (e.g., ARM Chi bus). Each data request can be a 64-byte memory access request. A key function of transaction buffer 150 is its ability to generate a trigger signal upon receiving the first access request. The first access request here refers to the first data request received by transaction buffer 150 when the adaptive controller 130 is not currently handling a merging batch (i.e., the previous batch has been sent and the system is in an idle waiting state). For example, assuming the transmitting device has just completed a round of data transmission and transaction buffer 150 is empty, the first 64-byte read request arriving at this time is considered the first access request, and its arrival triggers the entire device to begin a new round of transmission decision-making.

[0086] The adaptive controller 130 is coupled to both the threshold comparator 120 and the transaction buffer 150. As the core scheduling unit of the entire device, the adaptive controller 130 responds to trigger signals from the transaction buffer 150 and generates corresponding control commands based on the link status signals output by the threshold comparator 120. In specific implementations, the adaptive controller 130 is configured with two different operating modes. When the link status signal indicates an idle state, the adaptive controller 130 controls the encapsulation and packetizing unit 160 to immediately package and send the currently received data requests, without initiating any timing operations, thus achieving pass-through to the forwarding layer. When the link status signal indicates a congested state, the adaptive controller 130 controls the encapsulation and packetizing unit 160 to package and send the collected data requests when the sending conditions are met. In this case, a waiting and merging process needs to be initiated to collect more mergeable data requests.

[0087] Dynamic timer 140, coupled to adaptive controller 130, receives enable signals and window configuration parameters from adaptive controller 130 and performs timing operations based on these parameters. Unlike fixed-duration timers, the waiting time of dynamic timer 140 can be dynamically adjusted according to the link congestion level. When the timing ends, dynamic timer 140 sends a timeout signal to adaptive controller 130, informing adaptive controller 130 that the waiting time has expired and transmission should be triggered.

[0088] Encapsulator 160 is coupled to both the adaptive controller 130 and the transaction buffer 150. Upon triggering by the adaptive controller 130, encapsulator 160 receives data requests to be sent from the transaction buffer 150, encapsulates these data requests into 256-byte Flit frames (i.e., physical frames) according to the CXL protocol specification, and then sends them to the physical layer. It should be noted that encapsulator 160 can receive a single data request for individual encapsulation, or it can receive multiple mergeable data requests for merged encapsulation, depending on the triggering timing of the adaptive controller 130 and the number of data requests already collected in the transaction buffer 150.

[0089] The link layer interface, acting as an external signal source, is responsible for receiving raw control messages from the CXL physical link and transmitting the update Flit, which contains credit update information, to the credit monitoring module 110. In essence, the link layer interface is a bridge connecting the physical link and the data transmission device, enabling the credit monitoring module 110 to obtain real-time information on changes in creditworthiness at the receiving end.

[0090] Regarding the connection relationships among the aforementioned modules, the output of the link layer interface is connected to the input of the credit rating monitoring module 110, forming a closed-loop feedback loop from the physical link to the protocol processing layer. The output of the credit rating monitoring module 110 is connected to the input of the threshold comparator 120 to achieve real-time transparent transmission of credit rating data. The output of the threshold comparator 120 is connected to the input of the adaptive controller 130 to send quantized link status signals. The control output of the adaptive controller 130 is connected to the input of the dynamic timer 140 to send enable signals and window configuration instructions; the output of the dynamic timer 140 is connected back to the adaptive controller 130 to provide feedback on timeout signals. The adaptive controller 130 also outputs a merging control signal to the transaction buffer 150 and directly drives the trigger of the encapsulation packer 160. The data output of the transaction buffer 150 is connected to the data input of the encapsulation packer 160 to transmit data requests to be sent.

[0091] Through the above structure, this embodiment achieves the following technical effects: First, since the credit monitoring module 110 can acquire the credit value of the receiving end in real time, the threshold comparator 120 can compare the value with a preset threshold and output a link status signal. The adaptive controller 130 can select different transmission strategies according to the status signal, thus the transmitting device has the ability to sense and respond to changes in link status. Second, when the link is idle, the adaptive controller 130 controls the encapsulator 160 to immediately encapsulate and send the current data request without starting any timer, thereby eliminating the unavoidable waiting delay in the fixed timer scheme. Third, when the link is congested, the adaptive controller 130 starts the dynamic timer 140 and sets a corresponding timing window. Within the window, it waits to collect more data requests that can be merged, and at the same time, it triggers transmission under the dual conditions of timer timeout or collection quantity reaching a set value. This allows data to be compressed as much as possible before transmission in congested conditions, increasing the effective payload ratio of each data frame, thereby improving bandwidth utilization. Finally, since the credit score value changes in real time, the preset threshold of the threshold comparator 120 is programmable, and the window parameters of the dynamic timer 140 can be dynamically configured according to the degree of congestion, the entire device has dynamic adaptive capability and can automatically adjust to a better working state under different load conditions.

[0092] Based on the above implementation, this application also provides a chip that integrates the above-described data transmission device.

[0093] In summary, the solution provided in this application has the following beneficial effects: 1. Cross-layer closed-loop feedback mechanism based on link layer credit limit.

[0094] The solution provided in this application breaks through the limitations of open-loop merging in traditional controllers, establishing a real-time feedback loop from the physical link layer to the transaction layer. Specifically, this application utilizes the native flow control credit limit of the CXL protocol as the determination source for merging triggers. The credit limit monitoring module 110 captures the receiving capacity of the remote device in real time and adjusts the data encapsulation rhythm of the local end accordingly. It should be noted that the credit limit is the core mechanism for flow control in the CXL protocol; it represents the available buffer capacity of the receiving end. The higher the credit limit value, the more abundant the processing capacity of the receiving end. By sensing this credit limit in real time, the sending end no longer blindly executes fixed waiting, but can dynamically adjust its sending strategy according to the actual processing capacity of the receiving end.

[0095] 2. Congestion classification decision logic based on multi-level threshold quantization.

[0096] This application introduces a threshold comparator 120, which includes a programmable first preset threshold and a second preset threshold. These two programmable thresholds quantify consecutive credit limit values ​​into different congestion levels, such as idle state, first congestion state, and second congestion state. In practical applications, when the real-time credit limit is greater than the first preset threshold, it is determined to be in an idle state; when the real-time credit limit is less than the second preset threshold, it is determined to be in a second congestion state; and when the credit limit is between the two, it is in a first congestion state. This scheme implements a non-linear mapping of the merging strategy, avoiding system performance oscillations caused by simple all-on or all-off binary decisions. Understandably, this tiered control logic ensures that the system can find the most suitable latency and bandwidth balance point under different pressure levels, avoiding unnecessary latency during idle periods and preventing premature transmission of incomplete data frames during congestion.

[0097] 3. Zero-latency pass-through triggering technology under low load.

[0098] This application explicitly defines that when the credit limit is sufficient (i.e., the real-time credit limit is greater than a first preset threshold), the adaptive controller 130 directly outputs a trigger signal to the encapsulator 160, completely skipping the waiting process of the dynamic timer 140. In specific implementation, when the threshold comparator 120 determines that the current link is idle, the adaptive controller 130 outputs a bypass instruction, does not start the dynamic timer 140, and directly drives the transaction buffer 150 and the encapsulator 160 to complete zero-latency forwarding. This method solves the problem of artificial delays caused by merging operations under the CXL protocol. Through a pass-through design at the hardware logic level, it ensures that when the link is idle, memory access requests can penetrate the controller with near-zero waiting time, thereby eliminating the unavoidable waiting delay in traditional fixed-timer schemes.

[0099] 4. Dynamic parameterized configuration of merged window time.

[0100] In this scheme, the initial countdown value of the dynamic timer 140 is not fixed, but is assigned in real time by the adaptive controller 130 according to the congestion level. Specifically, when the threshold comparator 120 determines that the credit limit is lower than the second preset threshold (i.e., in a congested state), the adaptive controller 130 sends an enable signal and the corresponding window time parameter to the dynamic timer 140. The window time parameter is negatively correlated with the link congestion level; the more severe the congestion, the longer the timing window; the less severe the congestion, the shorter the timing window. In cases of severe congestion, the system automatically extends the window to compact more data; in cases of mild congestion, the system shortens the window accordingly to avoid excessive waiting. This design of dynamically allocating waiting time is a direct execution unit for improving physical bandwidth utilization (i.e., effective throughput), enabling the system to achieve optimal data compaction under different congestion levels.

[0101] 5. Asynchronous decoupling of control logic and data path.

[0102] In this application, the entire triggering architecture, consisting of the credit monitoring module 110, threshold comparator 120, adaptive controller 130, and dynamic timer 140, serves as a bypass control plane, decoupled from the data storage plane of the transaction buffer 150. It should be noted that this decoupling design means that the adaptive controller 130 only issues pop-up or wait instructions without changing the storage format or content of the data within the transaction buffer 150. The control logic and data path are separated; the controller focuses on deciding when to send, while the transaction buffer 150 focuses on how to store the data. This architecture significantly reduces the complexity of hardware implementation because the control plane and data plane can be designed and verified independently. Simultaneously, this decoupling design improves compatibility with different protocol types; both the CXL.mem and CXL.cache protocols can be processed through the same control architecture without requiring a redesign of the data path for each protocol.

[0103] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0104] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A data transmission method, characterized in that, The data transmission method includes: Real-time capture and parsing of credit score update information from the link layer to obtain the current real-time credit score value; When the first access request is received, the real-time credit score value is compared with a preset threshold, and the current link status is determined based on the comparison result; wherein, the link status includes idle state and congestion state, and the first access request is used to characterize the first data request received by the transaction buffer when the adaptive controller is in a state where there is no ongoing merging batch; When in an idle state, immediately package and send the currently received data request; When in a congested state, a timing window is started, within which mergeable data requests are collected, and when the timing window times out or the number of collected data requests reaches a set value, the collected data requests are packaged and sent. The congestion state includes a first congestion state and a second congestion state, wherein the congestion level of the first congestion state is less than that of the second congestion state; when in a congestion state, the step of starting the timing window includes: When in a congested state, the duration of the timing window is dynamically configured based on the real-time credit score value. The duration of the timing window is negatively correlated with the real-time credit score value. Specifically, when in the first congested state, the sensitivity of the timing window duration to changes in the credit score value is a first sensitivity; when in the second congested state, the sensitivity of the timing window duration to changes in the credit score value is a second sensitivity; wherein, the second sensitivity is greater than the first sensitivity. Alternatively, when in a congested state, the steps to start the timing window include: When in the second congestion state, start the longest timer window; When in the first stage of congestion, determine the current link trend; When the current link approaches an idle state, shorten the duration of the timing window; When the current link tends to the second congestion state, extend the duration of the timing window.

2. The data transmission method according to claim 1, characterized in that, Before the step of packaging and sending the collected data requests when the timeout window expires or the number of collected data requests reaches a set value, the method further includes: The set value is determined based on the relationship between the real-time credit score value, the preset value, and the set value.

3. The data transmission method according to claim 1, characterized in that, The steps for immediately packaging and sending the currently received data request include: Disable the start of the timer and directly trigger the packaging and sending of data requests.

4. The data transmission method according to claim 1, characterized in that, The data requests that can be merged are those that are adjacent to the address of the first access request or that meet the preset merging conditions.

5. The data transmission method according to claim 1, characterized in that, The steps for capturing and parsing credit score update information from the link layer in real time to obtain the current real-time credit score value include: The received CXL protocol update packets are parsed in real time, and the available credit limit corresponding to the CXL.cache and CXL.mem protocols is extracted. The available credit limit is used as the real-time credit limit value.

6. A data transmission device, characterized in that, For performing the data transmission method as described in any one of claims 1 to 5, the data transmission apparatus includes: The credit rating monitoring module is used to capture and parse credit rating update information from the link layer in real time to obtain the current real-time credit rating value. A threshold comparator, coupled to the credit monitoring module, is used to compare the real-time credit score with a preset threshold and output the current link status signal based on the comparison result; wherein, the link status includes idle state and congestion state; A transaction buffer is used to receive and temporarily store data requests, and to generate a trigger signal when the first access request is received; the first access request is used to represent the first data request received when there is no ongoing merge batch. An adaptive controller, coupled to the threshold comparator and the transaction buffer respectively, is used to generate corresponding control commands based on the status signals of the link in response to the trigger signal; A dynamic timer, coupled to the adaptive controller, is used to receive the enable signal and window configuration parameters issued by the adaptive controller, perform timing operations, and feed back a timeout signal to the adaptive controller when the timing ends. A packaging and packaging unit is coupled to the adaptive controller and the transaction buffer respectively, and is used to receive data requests from the transaction buffer when triggered by the adaptive controller, and to package and send them. The adaptive controller is configured as follows: When the status signal of the link indicates an idle state, the encapsulator is controlled to immediately encapsulate and send the currently received data request; When the status signal of the link indicates a congestion state, the encapsulator is controlled to package and send the collected data requests when the sending conditions are met; the sending conditions include: receiving the timeout signal of the dynamic timer, or the number of data requests collected by the transaction buffer reaching a set value.

7. A chip, characterized in that, The chip integrates the data transmission device as described in claim 6.

Images