Link training method and system, communication apparatus, and chip

By sending frames in the communication system to indicate the execution of the second link training, the problems of waiting for response or timeout during link training are solved, achieving more efficient link training and fault tolerance, and improving link performance.

WO2025232702A1PCT designated stage Publication Date: 2025-11-13HUAWEI TECH CO LTD
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2025/092659
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-05-09
Filing Date
2025-04-30
Publication Date
2025-11-13

AI Technical Summary

Technical Problem

In communication systems, during the link training process between devices, existing technologies are prone to inefficiency due to waiting for responses or frame lock timeouts, and lack fault tolerance mechanisms, which affect link performance.

Method used

By sending frames from the first device to the second device to instruct the execution of the second link training, the system avoids waiting for a response or timeout of the locked frame, adopts proactive measures to promote error recovery, and provides a fault tolerance mechanism.

Benefits of technology

It improves the efficiency and fault tolerance of link training, reduces adverse consequences caused by waiting for response or frame lock timeout, and enhances link performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2025092659_13112025_PF_FP_ABST
    Figure CN2025092659_13112025_PF_FP_ABST
Patent Text Reader

Abstract

The present application belongs to the technical field of communications. Disclosed are a link training method and system, a communication apparatus, and a chip. The method comprises: a first device sending a first frame to a second device, wherein the first frame instructs the second device to execute first link training; and then, in response to the first device failing to detect a response from the second device, or in response to the first device failing to lock the frame, the first device sending a second frame to the second device, wherein the second frame instructs the second device to execute second link training. The present application improves the efficiency of link training, and provides a fault-tolerant mechanism, thereby facilitating rapid recovery from errors during link training.
Need to check novelty before this filing date? Find Prior Art

Description

Methods, systems, communication devices and chips for link training

[0001] This application claims priority to Chinese Patent Application No. 202410574584.7, filed on May 9, 2024, entitled “Method, System, Communication Device and Chip for Link Training”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to methods, systems, communication devices and chips for link training. Background Technology

[0003] In the field of communication technology, communication systems comprise different devices connected via at least one channel, either optical or telecommunication. After a link is established between the different devices, link parameters need to be obtained through a link training process in order to improve link performance based on these parameters. Summary of the Invention

[0004] This application provides a method, system, communication device, and chip for link training to achieve link training. The technical solution provided by this application includes the following aspects.

[0005] In a first aspect, a method for link training is provided, in which: a first device sends a first frame to a second device, the first frame instructing the second device to perform first link training. Subsequently, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, the second frame instructing the second device to perform second link training.

[0006] In this application, the first device sends a first frame to the second device to instruct the second device to perform first link training. Subsequently, if the first device does not recognize a response from the second device, it can also send a second frame to the second device to instruct the second device to perform second link training, instead of continuously waiting for a response from the second device until a timeout occurs. Alternatively, even if the first device does not lock a frame, it can still send a second frame to the second device to instruct the second device to perform second link training, instead of continuously waiting for a frame lock until a timeout occurs.

[0007] Therefore, this application avoids the first device from remaining in the stage of waiting for the response from the second device or waiting for frame locking, thus avoiding timeouts caused by this pause and consequently avoiding adverse consequences such as consuming a long time to restart the link training process. Thus, this application not only improves the efficiency of link training but also provides a fault-tolerance mechanism. Specifically, in the event of errors (or malfunctions) such as the first device failing to recognize the response from the second device or the first device being unable to lock a frame, the first device does not passively wait for error recovery but actively sends a second frame to instruct the second device to perform second link training, thereby promoting error recovery. This gives the link training a certain degree of fault tolerance and improves the error recovery speed.

[0008] In one possible implementation, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the maximum waiting timer during link training.

[0009] Therefore, if the duration of the undetected response from the second device is less than the timeout duration of the maximum waiting timer, the first device can send the second frame to the second device, thus avoiding the timeout of the maximum waiting timer and improving the efficiency of link training.

[0010] In one possible implementation, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the silent state.

[0011] If the duration for which the response from the second device is not detected is less than the timeout duration of the maximum silent state, the first device can send a second frame to the second device, thus avoiding triggering the silent state and improving the efficiency of link training.

[0012] In one possible implementation, the first device not recognizing the response of the second device includes: the first device not recognizing the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the recovery state.

[0013] If the duration for which the response from the second device is not detected is less than the timeout duration of the maximum recovery state, the first device can send a second frame to the second device, thus avoiding triggering the recovery state and improving the efficiency of link training.

[0014] In one possible implementation, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within 20 milliseconds after sending the first frame.

[0015] If the duration of the unrecognized response from the second device is less than 20 milliseconds, the first device can send the second frame to the second device, thus avoiding the 20-millisecond wait for the first device to recognize the response from the second device after sending the first frame, thereby improving the efficiency of link training.

[0016] In one possible implementation, the first device is not locked to a frame, including: the first device is not locked to a frame within 20 milliseconds after sending the first frame.

[0017] When the duration of the unlocked frame is less than 20 milliseconds, the first device can send the second frame to the second device, avoiding the 20-millisecond wait time for the first device to recognize the response from the second device after sending the first frame, thus improving the efficiency of link training.

[0018] In one possible implementation, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, including: in response to the first device not recognizing the second device, or in response to the first device not locking a frame, without entering the initialization state or silent state of the first device's state machine, the first device directly sends a second frame to the second device.

[0019] This avoids the first device's state machine entering an initialization or silent state, which could lead to adverse consequences such as restarting the link training and improves the efficiency of link training.

[0020] In one possible implementation, the second frame instructs the second device to interrupt the first link training and perform the second link training.

[0021] This implementation avoids interference between the first and second training links, making it highly practical.

[0022] In one possible implementation, the second frame includes a preset request that triggers the second device to perform second link training.

[0023] The second device is triggered to perform the second link training by a preset request, which is a simple and quick method.

[0024] In one possible implementation, the second frame includes first request information, which requests the second device to perform second link training based on the historical training state prior to the first link training.

[0025] Because the first request information in this implementation references the historical training state, the first request information is relatively accurate. This makes it more likely that after the second device performs the second link training based on the first request information, the first device can recover the recognition of the second device's response or recover the frame lock, thus improving the efficiency of link training.

[0026] In one possible implementation, the second frame includes second request information, which requests the second device to perform second link training in the current training state of the first link training.

[0027] This implementation method is relatively flexible and has strong scalability.

[0028] In one possible implementation, before the first device sends a second frame to the second device in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the method further includes: the first device sending a third frame to the second device, the third frame including a training type and the training type indicating individual parameter control, or the third frame including a hold request or the training parameters included in the third frame being different from the training parameters included in the first frame.

[0029] In this implementation, after the first device sends the first frame and before sending the second frame, it also sends a third frame to the second device. This third frame helps to trigger a state change in the second device, so that after the second device receives the second frame, it can quickly perform the second link training based on the second frame, thereby improving the efficiency of link training.

[0030] Secondly, a link training method is provided, in which: when the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training.

[0031] In this context, after the second device receives the first frame from the first device, the state machine of the second device can be in a new initial condition state or a new request state.

[0032] Regardless of the state, the second device can perform second link training based on the second frame upon receiving it, ensuring the normal progress of the link training process and demonstrating high reliability.

[0033] In one possible implementation, when the state machine of the second device is in a new request state, in response to the following condition being met, the state machine of the second device jumps from the new request state to another new initial condition state: the second frame includes a second training type, which indicates non-individual parameter control.

[0034] By setting conditions, the second device can switch between a new request state and a new initial condition state, which is beneficial for the second device to achieve link training in a more flexible way.

[0035] In one possible implementation, when the state machine of the second device is in a new initial condition state, in response to the following condition being met, the state machine of the second device jumps from the new initial condition state to another new initial condition state: the second frame includes a second training type, the second training type indicates non-individual parameter control and indicates a second preset mode, the second preset mode being different from the first preset mode indicated by the first training type included in the first frame, the first frame being a frame received by the second device from the first device, the first frame instructing the second device to perform first link training.

[0036] By setting conditions, the second device can switch between different new initial condition states, which is beneficial for the second device to achieve link training in a more flexible way.

[0037] In one possible implementation, when the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: when the state machine of the second device is in a new initial condition state, in response to receiving a third frame from the first device, the state machine of the second device jumps from the new initial condition state to a new index state, wherein the third frame includes a training type and the training type indicates individual parameter control; when the state machine of the second device is in a new index state, in response to receiving the second frame, the second device performs second link training.

[0038] This approach is well compatible with the new initial condition states of the state machine of the second device.

[0039] In one possible implementation, when the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: when the state machine of the second device is in a new request state, in response to receiving a third frame from the first device, the state machine of the second device transitions from the new request state to a waiting state, wherein the third frame includes a hold request or the training parameters included in the third frame are different from the training parameters included in the first frame; when the state machine of the second device is in a waiting state, in response to receiving the second frame, the second device performs second link training.

[0040] This approach is well compatible with the new request states available in the state machine of the second device.

[0041] In some possible implementations, the second device performs second link training based on the second frame, including: the second device interrupts the first link training based on the second frame and performs second link training.

[0042] In some possible implementations, the second frame includes a preset request, and the second device interrupts the first link training according to the second frame and performs the second link training, including: the second device performs the second link training according to the preset request.

[0043] In some possible implementations, the second frame includes first request information, and the second device interrupts the first link training according to the second frame and performs second link training, including: the second device performs second link training based on the historical training state before the first link training according to the first request information.

[0044] In some possible implementations, the second frame includes second request information, and the second device interrupts the first link training according to the second frame and performs second link training, including: the second device performs second link training according to the second request information in the current training state of the first link training.

[0045] Thirdly, a link training apparatus is provided, the apparatus comprising:

[0046] The transmitting module is used for the first device to send a first frame to the second device, the first frame instructing the second device to perform the first link training;

[0047] The sending module is also configured to, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, send a second frame to the second device, the second frame instructing the second device to perform second link training.

[0048] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the maximum wait timer during link training.

[0049] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the silent state.

[0050] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the recovery state.

[0051] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within 20 milliseconds after sending the first frame.

[0052] In some possible implementations, the first device is not frame-locked, including: the first device is not frame-locked within 20 milliseconds after transmitting the first frame.

[0053] In some possible implementations, the sending module is configured to, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, not enter the initialization state or silent state of the first device's state machine, and the first device directly sends the second frame to the second device.

[0054] In some possible implementations, the second frame instructs the second device to interrupt the first link training and perform the second link training.

[0055] In some possible implementations, the second frame includes a preset request that triggers the second device to perform second link training.

[0056] In some possible implementations, the second frame includes first request information, which requests the second device to perform second link training based on the historical training state prior to the first link training.

[0057] In some possible implementations, the second frame includes second request information, which requests the second device to perform second link training in the current training state of the first link training.

[0058] In some possible implementations, the sending module is further configured to: in response to a response that the first device does not recognize the second device, or in response to a response that the first device does not lock a frame, send a third frame to the second device before sending the second frame, the third frame including a training type and the training type indicating individual parameter control, or the third frame including a hold request or the training parameters included in the third frame being different from the training parameters included in the first frame.

[0059] Fourthly, a link training apparatus is provided, the apparatus comprising:

[0060] The execution module is used to perform second link training in response to receiving a second frame from the first device when the state machine of the second device is in a new initial condition state or a new request state.

[0061] In some possible implementations, when the state machine of the second device is in a new request state, in response to the following condition being met, the state machine of the second device jumps from the new request state to another new initial condition state: the second frame includes a second training type, which indicates non-individual parameter control.

[0062] In some possible implementations, when the state machine of the second device is in a new initial condition state, in response to the following condition being met, the state machine of the second device jumps from the new initial condition state to another new initial condition state: the second frame includes a second training type, the second training type indicates non-individual parameter control and indicates a second preset mode, the second preset mode is different from the first preset mode indicated by the first training type included in the first frame, the first frame is a frame received by the second device from the first device, the first frame instructs the second device to perform the first link training.

[0063] In some possible implementations, the execution module is configured to, when the state machine of the second device is in a new initial condition state, in response to receiving a third frame from the first device, transition the state machine of the second device from the new initial condition state to a new index state, wherein the third frame includes a training type and the training type indicates individual parameter control; when the state machine of the second device is in a new index state, in response to receiving a second frame, the second device performs second link training.

[0064] In some possible implementations, the execution module is configured to, when the state machine of the second device is in a new request state, in response to receiving a third frame from the first device, transition the state machine of the second device from the new request state to a waiting state, wherein the third frame includes a hold request or the training parameters included in the third frame are different from the training parameters included in the first frame; when the state machine of the second device is in the waiting state, in response to receiving the second frame, the second device performs second link training.

[0065] In some possible implementations, the second frame includes a preset request, and the second device interrupts the first link training according to the second frame and performs the second link training, including: the second device performs the second link training according to the preset request.

[0066] In some possible implementations, the second frame includes first request information, and the second device interrupts the first link training according to the second frame and performs second link training, including: the second device performs second link training based on the historical training state before the first link training according to the first request information.

[0067] In some possible implementations, the second frame includes second request information, and the second device interrupts the first link training according to the second frame and performs second link training, including: the second device performs second link training according to the second request information in the current training state of the first link training.

[0068] Fifthly, a communication device is provided, comprising a transceiver and a processor, wherein the transceiver performs transmission and reception functions, and the processor performs other functions besides transmission and reception functions, so that the communication device implements the link training method provided in the first aspect, the second aspect, and the corresponding possible implementations.

[0069] In a sixth aspect, a chip is provided, which includes an interface circuit and a control circuit. The interface circuit is used to transmit and receive data, and the control circuit is used to process the data, so that a device equipped with the chip can implement the following link training method.

[0070] The first device sends a first frame to the second device, and the first frame instructs the second device to perform the first link training.

[0071] In response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, the second frame instructing the second device to perform second link training.

[0072] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the maximum wait timer during link training.

[0073] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the silent state.

[0074] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the recovery state.

[0075] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within 20 milliseconds after sending the first frame.

[0076] In some possible implementations, the first device is not frame-locked, including: the first device is not frame-locked within 20 milliseconds after transmitting the first frame.

[0077] In some possible implementations, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, including:

[0078] In response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device does not enter the initialization state or silent state of its state machine, and directly sends the second frame to the second device.

[0079] In some possible implementations, the second frame instructs the second device to interrupt the first link training and perform the second link training.

[0080] In some possible implementations, the second frame includes a preset request that triggers the second device to perform second link training.

[0081] In some possible implementations, the second frame includes first request information, which requests the second device to perform second link training based on the historical training state prior to the first link training.

[0082] In some possible implementations, the second frame includes second request information, which requests the second device to perform second link training in the current training state of the first link training.

[0083] In some possible implementations, before the first device sends a second frame to the second device in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the method further includes: the first device sending a third frame to the second device, the third frame including a training type and the training type indicating separate parameter control, or the third frame including a hold request or the training parameters included in the third frame being different from the training parameters included in the first frame.

[0084] In a seventh aspect, another chip is provided, which includes an interface circuit and a control circuit. The interface circuit is used to transmit and receive data, and the control circuit is used to process the data, so that the second device with the chip installed can implement the following link training method:

[0085] When the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training.

[0086] In some possible implementations, when the state machine of the second device is in a new request state, in response to the following condition being met, the state machine of the second device jumps from the new request state to another new initial condition state: the second frame includes a second training type, which indicates non-individual parameter control.

[0087] In some possible implementations, when the state machine of the second device is in a new initial condition state, in response to the following condition being met, the state machine of the second device jumps from the new initial condition state to another new initial condition state: the second frame includes a second training type, the second training type indicates non-individual parameter control and indicates a second preset mode, the second preset mode is different from the first preset mode indicated by the first training type included in the first frame, the first frame is a frame received by the second device from the first device, the first frame instructs the second device to perform the first link training.

[0088] In some possible implementations, when the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: when the state machine of the second device is in a new initial condition state, in response to receiving a third frame from the first device, the state machine of the second device jumps from the new initial condition state to a new index state, wherein the third frame includes a training type and the training type indicates individual parameter control; when the state machine of the second device is in a new index state, in response to receiving a second frame, the second device performs second link training.

[0089] In some possible implementations, when the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: when the state machine of the second device is in a new request state, in response to receiving a third frame from the first device, the state machine of the second device transitions from the new request state to a waiting state, wherein the third frame includes a hold request or the training parameters included in the third frame are different from the training parameters included in the first frame; when the state machine of the second device is in a waiting state, in response to receiving the second frame, the second device performs second link training.

[0090] Eighthly, a link training system is provided, the system including a first device and a second device, the first device being used to execute the link training method provided by the first aspect or any possible implementation of the first aspect, and the second device being used to execute the link training method provided by the second aspect or any possible implementation of the second aspect.

[0091] It should be understood that the technical effects achieved by the technical solutions provided by the third to eighth aspects of this application and their corresponding possible implementations can be found in the above description of the technical effects achieved by the technical solutions provided by the first and second aspects and their corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0092] Figure 1 is a schematic diagram of a link training process provided in an embodiment of this application;

[0093] Figure 2 is a schematic diagram of a communication system provided in an embodiment of this application;

[0094] Figure 3 is a schematic diagram of another communication system provided in an embodiment of this application;

[0095] Figure 4 is a schematic diagram of another communication system provided in an embodiment of this application;

[0096] Figure 5 is a schematic diagram of another communication system provided in an embodiment of this application;

[0097] Figure 6 is a schematic diagram of the structure of a half retimed module provided in an embodiment of this application;

[0098] Figure 7 is a schematic diagram of another half retimed module provided in an embodiment of this application;

[0099] Figure 8 is a structural schematic diagram of an LPO optical module provided in an embodiment of this application;

[0100] Figure 9 is a schematic diagram of another LPO optical module provided in an embodiment of this application;

[0101] Figure 10 is a schematic diagram of the LT state machine of a first device provided in an embodiment of this application;

[0102] Figure 11 is a schematic diagram of an LT frame provided in an embodiment of this application;

[0103] Figure 12 is a schematic diagram of the LT state machine of another first device provided in an embodiment of this application;

[0104] Figure 13 is a flowchart of a link training method provided in an embodiment of this application;

[0105] Figure 14 is a schematic diagram of the LT state machine of a second device provided in an embodiment of this application;

[0106] Figure 15 is a schematic diagram of the LT state machine of another second device provided in an embodiment of this application;

[0107] Figure 16 is a flowchart illustrating a link training method provided in an embodiment of this application;

[0108] Figure 17 is a schematic diagram of a link parameter space provided in an embodiment of this application;

[0109] Figure 18 is a schematic diagram of another link parameter space provided in an embodiment of this application;

[0110] Figure 19 is a schematic diagram of a cache update process provided in an embodiment of this application;

[0111] Figure 20 is a flowchart of another link training method provided in an embodiment of this application;

[0112] Figure 21 is a schematic diagram of the LT state machine of another second device provided in an embodiment of this application;

[0113] Figure 22 is a schematic diagram of the LT state machine of another second device provided in an embodiment of this application;

[0114] Figure 23 is a schematic diagram of the LT state machine of another second device provided in an embodiment of this application;

[0115] Figure 24 is a schematic diagram of the structure of a link training device provided in an embodiment of this application;

[0116] Figure 25 is a schematic diagram of another link training device provided in an embodiment of this application. Detailed Implementation

[0117] The terminology used in the implementation section of this application is for the purpose of explaining specific embodiments of this application only, and is not intended to limit this application.

[0118] In a communication system, different devices are connected via channels, which include at least one of optical or telecommunication channels. After a link is established between different devices, a link training (LT) process is performed. The link training process is a link initialization mechanism defined by the physical medium dependent (PMD) layer. Through the link training process, the link parameters associated with the transmitter (TX) connected to the link are trained, thereby optimizing the transmission performance of the TX and thus affecting the performance of the link.

[0119] Taking the first and second devices as examples of different devices performing the link training process, the first and second devices are partners in the link training process. As shown in Figure 1, the interface (port) of the first device includes a first TX, a first receiver (RX), and a first LT algorithm module, which is also called an LT control device. The interface of the second device includes a second TX, a second RX, and a second LT algorithm module. The link between the first and second devices includes a first sub-link and a second sub-link, and the link between the first and second devices is a full-duplex link. The first sub-link is the sub-link between the first TX and the second RX, and the transmission direction of the first sub-link is from the first device to the second device, that is, the first sub-link is used for the first device to transmit signals to the second device. The second sub-link is the sub-link between the second TX and the first RX, and the transmission direction of the second sub-link is from the second device to the first device, that is, the second sub-link is used for the second device to transmit signals to the first device. Based on this, the link training process between the first and second devices includes the training process of the first sub-link and the training process of the second sub-link.

[0120] Specifically, during the training process of the first sub-link, the second device trains the associated link parameters of the first device's first TX via the second RX to optimize the transmission performance of the first device's first TX. After training the associated link parameters of the first TX, the associated link parameters of the second RX can also be adjusted. During the training process of the first sub-link, the second device is the local end, and the first device is the remote end.

[0121] Alternatively, during the training process of the second sub-link, the first device trains the associated link parameters of the second device's second TX via the first RX to optimize the transmission performance of the second device's second TX. After training the associated link parameters of the second TX, the associated link parameters of the first RX can also be adjusted. During the training process of the second sub-link, the first device is the local end, and the second device is the peer end.

[0122] Considering that the training processes for the first and second sub-links are based on the same principle, this embodiment of the application will use the training process of the second sub-link as an example for explanation, and the training process of the first sub-link will not be described in detail.

[0123] The training process of the second sub-link includes at least one link parameter setting process. Taking one link parameter setting process as an example, the first device sets the associated link parameters of the second device's second TX through the first RX. Specifically, referring to Figure 1, the first RX detects the signal status of the second sub-link, the first LT algorithm module generates an LT frame based on the signal status, the first TX sends the LT frame to the second RX, the second RX sends the LT frame to the second LT algorithm module, and the second LT algorithm module controls the second TX to set the associated link parameters of the second TX based on the LT frame. After a link parameter setting process in the training process of the second sub-link is completed, if the signal status of the second sub-link detected by the first RX meets the requirements, the second TX can subsequently send signals to the first RX according to the associated link parameters of the second TX set in that link parameter setting process, and the training process of the second sub-link ends.

[0124] For example, signal states include, but are not limited to, signal-to-noise ratio (SNR), bit error rate (BER), or eye pattern. For instance, if the signal state is BER, meeting the requirement could mean that the detected BER value is less than the BER threshold. However, this application does not limit the use of BER as the criterion for determining whether a signal state meets the requirement.

[0125] For example, the associated link parameters of the second TX include, but are not limited to, the equalizer coefficient and optical modulation amplitude (OMA), chirp / dispersion (CD), differential swing, drive current, or digital pre-distortion (DPD) of the second TX. For example, the equalizer includes a finite impulse response filter (FIR-Filter), therefore, the equalizer parameters include FIR-Filter parameters. The equalizer parameters can affect the pre-emphasis and signal amplitude of the second TX. OMA and CD can affect the attenuation of the signal transmitted by the second TX during transmission. Differential swing includes, but is not limited to, the drive voltage swing of the second TX's driver, which can affect the noise of the signal transmitted by the second TX. Drive current includes, but is not limited to, the drive current of the laser in the second TX, which can affect the power of the signal transmitted by the second TX. DPD can affect the nonlinear distortion of the second TX. Therefore, the various associated link parameters of the second TX exemplified herein can affect the performance of the second sub-link.

[0126] This application provides a communication system comprising at least two devices, wherein different devices among the at least two devices are capable of performing the aforementioned link training process. Adjacent devices among the at least two devices are connected via an optical channel or a telecommunication channel. When the communication system includes a telecommunication channel but not an optical channel, it can also be called an electrical interconnection system. When the communication system includes both a telecommunication channel and an optical channel, it can also be called an optoelectronic interconnection system.

[0127] For example, a telecom channel includes twin-ax copper cable (C), backplane (K), or printed circuit board (PCB), etc. For instance, a telecom channel is suitable for network scenarios involving high-speed Ethernet interfaces, such as cables, backplanes, or PCBs defined by specifications like 400GBASE-CR8 / KR8, 800GBASE-CR8 / KR8, or 1.6T. Here, 400GBASE indicates support for a transmission rate of 400 gigabits per second (Gbps), 800GBASE indicates support for a transmission rate of 800 Gbps, and 1.6T indicates support for a transmission rate of 1.6 terabit per second (Tbps). CR8 represents an 8-channel twin-ax copper cable, KR8 represents an 8-channel backplane, and R represents scrambled.

[0128] For example, an optical channel includes optical fiber. For instance, an optical channel is suitable for devices involving high-speed optoelectronic interconnect systems, such as those using the Ultra Ethernet Consortium (UEC) or Multi Source Agreement (MSA).

[0129] In exemplary embodiments, the devices in the communication system provided in this application include, but are not limited to, the following.

[0130] The first type of device is the host chip, also known as the main chip within the device, which is connected to other devices via telecommunications channels. For example, host chips include, but are not limited to, switch chips or physical layer (PHY) chips, such as application-specific integrated circuit (ASIC) chips.

[0131] The second type of device is the electrical interconnect device, which connects to other devices via telecommunication channels. For example, electrical interconnect devices include direct attach cables (DACs), which include, but are not limited to, active electrical cables (AEC) modules, active copper cables (ACC) modules, or passive direct attach cable DAC modules.

[0132] The third type of device is the optoelectronic interconnect device, which is used for optoelectronic conversion and is connected to other devices through optical channels, or to other devices through optical channels and telecommunication channels.

[0133] In some implementations, the optoelectronic interconnect device includes an optical module. Exemplarily, the optical module includes, but is not limited to, an optical digital signal processor (oDSP) optical module, a linear-drive pluggable optics (LPO) optical module, or a half-retimed module, where a half-retimed module refers to a retimed transmitter linear receiver.

[0134] In other embodiments, the optoelectronic interconnect device includes co-package optics (CPO) modules or near-package optics (NPO) modules. Specifically, a CPO module can be obtained by co-assembling the optical engines (OE) and the host chip, for example, by co-assembling them on a substrate to form a co-package of OE and host chip. An NPO module can be obtained by separately mounting the OE and the host chip on the same PCB to form a near-package of OE and host chip.

[0135] In some other embodiments, optoelectronic interconnect devices include active optical cables (AOCs), which are obtained by integrating optical modules and optical fibers.

[0136] The fourth type of device, other than the three types mentioned above, serves as a relay or driver. For example, the fourth type of device could be a retimer; however, this application does not limit this type of device, and it can be flexibly configured according to actual needs.

[0137] In a communication system, the devices described above can be located in different devices, such as switches or network interface cards (NICs). For ease of understanding, based on the following exemplary communication systems, using the different devices performing the link training process as the first and second devices as examples, we will illustrate the first and second devices.

[0138] The first type of communication system, as shown in Figure 2, includes a first device comprising a host chip 1 and an LPO optical module 1 connected via a telecommunication channel, and a second device comprising a host chip 2 and an LPO optical module 2 connected via a telecommunication channel. The LPO optical module 1 and the LPO optical module 2 are connected via an optical channel.

[0139] In the first communication system, the first device is a host chip 1 and the second device is an LPO optical module 1. Alternatively, the first device is an LPO optical module 1 and the second device is an LPO optical module 2. Alternatively, the first device is an LPO optical module 2 and the second device is a host chip 2.

[0140] The situation shown in Figure 2 is only an example. For example, in addition to being an LPO optical module, the first device can also be a half-retimed module as shown in Figure 6 or Figure 7 below.

[0141] The second type of communication system, as shown in Figure 3, includes a first device consisting of a host chip 1 and an oDSP optical module connected via a telecommunication channel, and a second device consisting of a host chip 2 and an LPO optical module connected via a telecommunication channel. The oDSP optical module and the LPO optical module are connected via an optical channel. This type of system is also referred to as a mixed insertion of oDSP optical modules and LPO optical modules.

[0142] The oDSP optical module includes an oDSP. A first side of the oDSP connects to the host chip 1; this first side can be referred to as the hostside. A second side of the oDSP connects to the transmitter optical sub-assembly (TOSA) and / or the receiver optical sub-assembly (ROSA); this second side can be referred to as the mediaside. This application does not limit the devices included in the hostside and mediaside. The first side communicates with the host chip 1 via a telecommunication channel. For example, a serializer / deserializer (serdes) located on the first side of the oDSP communicates with a Serdes located on the host chip 1 (not shown in Figure 3) via a telecommunication channel. The second side communicates with the TOSA / ROSA via a telecommunication channel. In one implementation, the TOSA / ROSA is located within the oDSP optical module. The TOSA / ROSA communicates with the LPO optical module of the second device via an optical channel. Compared to oDSP optical modules, LPO optical modules eliminate the oDSP. Because LPO optical modules eliminate the oDSP, a host chip is required for photoelectric channel compensation.

[0143] In the second communication system, the first device is a host chip 1 and the second device is an oDSP optical module. Alternatively, the first device is an oDSP optical module and the second device is an LPO optical module. Alternatively, the first device is an LPO optical module and the second device is a host chip 2.

[0144] The third type of communication system, as shown in Figure 4, includes a first device consisting of a host chip 1, a retimer, and an LPO optical module connected in sequence via a telecommunication channel, and a second device consisting of a CPO module, which includes an OE and a host chip 2. The LPO optical module and the CPO module are connected via an optical channel. This situation is also called mixed insertion of LPO optical modules and CPO modules.

[0145] In the third communication system, the first device is host chip 1 and the second device is a retimer. Alternatively, the first device is a retimer and the second device is an LPO optical module. Alternatively, the first device is an LPO optical module and the second device is a CPO module.

[0146] The fourth communication system, as shown in Figure 5, includes a first device comprising a host chip 1 and an oDSP optical module 1 connected via a telecommunication channel, and a second device comprising a host chip 2 and an oDSP optical module 2 connected via a telecommunication channel. The oDSP optical module 2 is connected to the oDSP optical module 1 via an optical channel. The structures of the oDSP optical module 1 and oDSP optical module 2 can be found in the description of the oDSP optical module in the second communication system above, and will not be repeated here.

[0147] In the fourth communication system, the first device is a host chip 1 and the second device is an oDSP optical module 1. Alternatively, the first device is an oDSP optical module 1 and the second device is an oDSP optical module 2. Alternatively, the first device is an oDSP optical module 2 and the second device is a host chip 2.

[0148] The fifth type of communication system includes a first device comprising a host chip 1 and a second device comprising a host chip 2, wherein the host chip 2 and the host chip 1 are connected via a telecommunication channel.

[0149] In the fifth communication system, the first device is host chip 1 and the second device is host chip 2.

[0150] For example, taking the first device as an optoelectronic interconnect device, several architectures of the first device are illustrated.

[0151] In the first architecture, the first device is an oDSP optical module. The oDSP optical module includes an internal microcontroller unit (MCU) and an oDSP. The oDSP optical module can implement the method provided in the embodiments of this application through the MCU and the oDSP.

[0152] The second architecture uses a half-retimed module as the first component.

[0153] In some implementations, referring to Figure 6, the half retimed module supports the inclusion of a lite digital signal processor (DSP), analog signal processor (ASP), or clock and data recovery (CDR) in either transmission direction. The half retimed module includes, but is not limited to, a lite DSP / ASP / CDR, an MCU, a continuous time linear equalizer (CTLE), a driver (DRV), a trans-impedance amplifier (TIA), a laser, a modulator, a photodetector (PD), a multiplexer (MUX), and a demultiplexer (DEMUX). The half retimed module can implement the methods provided in the embodiments of this application using a lite DSP / ASP / CDR.

[0154] In other embodiments, referring to Figure 7, the half-retimed module supports a CDR equipped with a DME transceiver and a MUX / DEMUX in either transmission direction. Therefore, the half-retimed module includes, but is not limited to, a CDR (equipped with a DME transceiver and MUX / DEMUX), an MCU, a CTLE, a DRV, a TIA, a laser, a modulator, a PD, a MUX, and a DEMUX. The half-retimed module can implement the methods provided in the embodiments of this application through a CDR (equipped with a DME transceiver and MUX / DEMUX).

[0155] The third architecture uses an LPO optical module as the first device. The LPO optical module can be based on the standard architecture shown in Figure 8. The standard architecture LPO optical module includes, but is not limited to, an MCU, CTLE, DRV, TIA, laser, modulator, PD, MUX, and DEMUX. This standard architecture LPO optical module connects to the control system via a common management interface specification (CMIS) interface, and implements the method provided in this application embodiment according to the control of the control system.

[0156] The CMIS interface is an out-of-band interface, meaning it is not part of the network interface. Besides the CMIS interface, embodiments of this application may also employ interfaces such as peripheral component interconnect express (PCIe), management data input / output (MDIO), or inter-integrated circuit (IIC, I2C), etc., without limitation.

[0157] In some implementations, the control system includes an off-chip processor (e.g., a central processing unit (CPU)) or a main control board, and is implemented in software, which is more flexible.

[0158] In other embodiments, the control system includes devices in the host chip, such as an MCU integrated in the host chip, which is not limited in this application.

[0159] In exemplary embodiments, when a CMIS interface or similar connection to the control system is used, a register is used in conjunction with the register to implement the method provided in the embodiments of this application. The register is used to store the contents of the first frame and the second frame provided in the embodiments of this application (the contents of the first frame and the second frame will be described in detail in the following method embodiments). The first device implements the method provided in the embodiments of this application through the control system, etc., which means that the control system performs a read operation on the register to implement the method provided in the embodiments of this application. For example, the control system performs a read operation on the register to obtain the contents of the first frame and the second frame stored in the register, generates the first frame and the second frame according to the obtained contents, and sends them to implement the method provided in the embodiments of this application. Of course, the control system can also perform write operations on the register according to actual needs, and the embodiments of this application do not limit this.

[0160] The fourth architecture uses an LPO optical module as the first device. The LPO optical module can be an improved architecture as shown in Figure 9. This improved architecture adds firmware, such as a digital / analog signal processing chip, to the standard architecture shown in Figure 8. This firmware acts as a co-processor for the MCU, forming an MCU with the digital / analog signal processing chip. This MCU with the digital / analog signal processing chip implements the method provided in the embodiments of this application, reducing reliance on software. For example, the digital / analog signal processing chip is the Lite CDR & DME Transceiver shown in Figure 9.

[0161] For example, the digital / analog signal processing chip can be integrated into the MCU, or it can be located in at least one of the CTLE or Laser and called by the MCU. The embodiments of this application do not limit the deployment location of the digital / analog signal processing chip in the LPO optical module.

[0162] For example, the fourth architecture is illustrated using an LPO optical module as the first device. When the first device is a CPO module or an NPO module, the CPO module or NPO module may also include an MCU equipped with a digital / analog signal processing chip, and the method provided in the embodiments of this application is implemented through this MCU equipped with the digital / analog signal processing chip.

[0163] Before introducing the link training method provided in the embodiments of this application, we will take the different devices that perform the link training process as the first device and the second device as examples to introduce two related technologies for link training.

[0164] In related technology one, see Figure 10, which shows the state changes of the LT state machine of the first device.

[0165] The state machine of the first device sequentially enters the initialization state and the send_tf state, enabling it to send LT frames (tf) to the second device. Subsequently, the state machine of the first device enters the train_local state and the train_remote state. The train_local state refers to the first device training the associated link parameters of the second device's second TX via the first RX, corresponding to the training process of the second sub-link described above. The train_remote state refers to the second device training the associated link parameters of the first device's first TX via the second RX, corresponding to the training process of the first sub-link described above. Here, we will use the train_local state, specifically the training process of the second sub-link, as an example for explanation.

[0166] After the state machine of the first device enters the train_local state, the first device starts the maximum wait timer (max_wait_timer).

[0167] If the training process of the second sub-link is completed within the timeout period of max_wait_timer (e.g., 12 seconds), the state machine of the first device ends the train_local state, enters the link_ready state, and enters the send_data state according to actual needs.

[0168] Alternatively, if the training process of the second sub-link is not completed within the timeout period of max_wait_timer, then the max_wait_timer timeout ends (max_wait_timer_done), the state machine of the first device ends the train_local state and enters the timeout state.

[0169] After entering the timeout state, the state machine of the first device may directly enter the training failure (training_failed) state, or it may first enter the quiet state and then enter the training_failed state. If the state machine of the first device enters the training_failed state, it needs to re-enter the initialize state, which is equivalent to restarting the training process of the second sub-link. Of course, the training process of the first sub-link will also be restarted accordingly. That is, after the state machine of the first device re-enters the initialize state, the link training process between the first and second devices is restarted.

[0170] Furthermore, even if the state machine of the first device does not enter the timeout state but is in the train_local state, it may still enter the quiet state if the duration of the first device's unlocked frame exceeds 20 milliseconds. Here, the first device's unlocked frame is equivalent to the local LT frame lock (local_tf_lock) being false. The definition of the first device's unlocked frame will be explained in the following method embodiments, and will not be elaborated here. When the use_quiet_in_training setting is true and the first device's state machine is in the train_local state, if local_tf_lock remains false for 20 milliseconds, the lost training lock (lost_training_lock) becomes true and the device enters the quiet state. Here, use_quiet_in_training being true indicates that the first device's state machine has the ability to enter the quiet state.

[0171] The reasons that might cause the state machine of the first device to enter the timeout or quiet state include: After the first device sends an LT frame to the second device, the second device sets the link parameters according to the LT frame (it should be understood that these link parameters refer to the link parameters associated with the second device's second TX), but these link parameters cause a performance degradation in the second sub-link. In this abnormal situation, the first device may be unable to receive signals through the second sub-link, and thus cannot complete the training process of the second sub-link within the timeout period of max_wait_timer. It can only enter the timeout and training_failed states after the timeout period of max_wait_timer is reached, restarting the training process of the second sub-link. Alternatively, in this abnormal situation, the first device may be unable to complete the frame locking within 20 milliseconds. In this case, the first device will enter the quiet and training_failed states after the unlocked frame period reaches 20 milliseconds, restarting the training process of the second sub-link, thus restarting the link training process between the first and second devices.

[0172] To facilitate understanding, the structure of the LT frame and the process of setting the link parameters during the training of the second sub-link will be explained separately.

[0173] Referring to Figure 11, which shows one structure of an LT frame, the contents of an LT frame are explained below.

[0174] The frame marker position occupies 4 bytes and can be, for example, 0xFFFF_0000.

[0175] The control field, occupying 16 bits, is used to set link parameters. For example, during the link parameter setting process in the training of the second sub-link, the control field in the LT frame sent by the first device is used by the first device to instruct the second device to set the associated link parameters of the second TX. A description of these 16 bits can be found in Table 1 below.

[0176] Table 1

[0177] Bits 13 to 11 are the initial condition request bits, representing the training type. When the initial condition request bit value is any value other than 000, the training type indicates non-individual parameter control, meaning multiple link parameters are set, or the values ​​of multiple link parameters are updated. When the initial condition request bit value is 000, the training type indicates individual parameter control, meaning only one link parameter is set, or only the value of one link parameter is updated.

[0178] Bits 4 to 2 are the coefficient select bits, used to represent the training parameters, or in other words, to select the coefficients to be set, i.e., to select the coefficients to be updated. Bits 1 to 0 are the coefficient request bits, used to represent the adjustment values ​​corresponding to the training parameters, and also represent the direction of adjustment.

[0179] In some implementations, the training type indicator is not controlled by a single parameter, and the value of the initial condition request bit can be determined to be a value other than 000 based on actual needs. Furthermore, if the coefficient request bit is set to 00, in this implementation, the coefficient request bit indicates a hold request.

[0180] Taking the link parameters as equalizer parameters as an example, the equalizer parameters include c(-3), c(-2), c(-1), c(0), and c(1). When the value of the initial condition request bit is 010, the training type is preset 1. preset 1 is used to set c(-3), c(-2), c(-1), c(0), and c(1) to certain values, such as normalized values.

[0181] In other implementations, the training type indicator is controlled by a separate parameter, and the value of the coefficient select bit can be determined according to actual needs. Furthermore, the value of the coefficient request bit can be determined to be a value other than 00, in which case the coefficient request bit represents a non-holding request.

[0182] For example, when the coefficient select bit is 101, the training parameter is c(-3). When the coefficient request bit is 01, the corresponding adjustment value of the training parameter is the increment. Therefore, the coefficient select bit and the coefficient request bit are used to increase the value of c(-3).

[0183] Therefore, the control domain can be categorized into two cases.

[0184] The first control domain is used to set multiple link parameters in the LT frame. Provided the initial condition request bit is not 000, its value can be set according to actual needs, indicating that the training type is not controlled by a single parameter. Furthermore, the coefficient request bit is fixed at 00, representing a hold request.

[0185] The second control domain is used to set a link parameter in the LT frame. The initial condition request bit is fixed at 000, indicating separate parameter control for the training type. The coefficient select bit can be set according to actual needs, representing the training parameters. Furthermore, provided that the coefficient request bit is not 00, its value can be set according to actual needs, representing the adjustment value corresponding to the training parameters; the coefficient request is a non-holding request.

[0186] The status field, occupying 16 bits, represents the setting status of the link parameters, manifested through the initial condition status and coefficient status. For example, during the link parameter setting process in the training of the second sub-link, the control field in the LT frame sent by the first device represents the setting status of the associated link parameters of the first TX of the first device. A description of these 16 bits can be found in Table 2 below.

[0187] Table 2

[0188] For example, the control domain and the state domain constitute a differential Manchester encoding (DME) domain. In addition to the DME domain, the LT frame may also include a pseudo random binary sequence (PRBS) domain, which is not limited in this embodiment. Furthermore, the link parameters that can be trained in the link training method provided in this embodiment are not limited to the link parameters described above, and may also include other link parameters extended according to actual needs, which will not be listed here.

[0189] Based on the LT frame structure shown in Figure 11, the setting process of one link parameter during the training process of the second sub-link can include the following two setting methods.

[0190] In the first setting method, when the first device is in send_tf state or train_local state, and the control domain in the LT frame is the first control domain mentioned above, the link parameter setting process includes the following steps A to D.

[0191] Step A: The first device sends LT frame 1 to the second device. In LT frame 1, the value of the initial condition request bit is a non-zero value set according to actual needs, and the coefficient request bit indicates hold.

[0192] Step B: The first device waits until it receives LT frame 2 from the second device, then proceeds to step C. In LT frame 2, the initial condition status bit indicates "updated," and the coefficient status bit indicates "not updated," meaning the second device has set the link parameters according to LT frame 1. The first device waits for LT frame 2, which means it waits for the second device to return to the ic_sts == updated state after UPDATE_IC. The second device's UPDATE_IC means that the second device updates all equalizer parameters of its second TX based on the current value of ic_req (i.e., the value of the initial condition request bit in LT frame 1), and the update result is stored in ic_sts (i.e., the initial condition status in LT frame 2). ic_sts is an enumerated variable, and its value can be either updated or not updated.

[0193] Step C: The first device sends LT frame 3 to the second device. In LT frame 3, the initial condition request bit indicates individual coefficient control, and the coefficient request bit indicates hold.

[0194] In step D, the first device waits until it receives LT frame 4 from the second device, at which point the current link parameter setting process ends, and it can proceed to the next link parameter setting process, including but not limited to proceeding to the next step A. In LT frame 4, both the initial condition status bit and the coefficient status bit indicate "not updated".

[0195] If the performance of the second sub-link degrades after the second device sets the link parameters according to LT frame 1, then: if the first device cannot receive LT frame 2 through the second sub-link, then the first device will continue to wait in step B until it enters a timeout state or a quiet state and cannot proceed to step C; or, if the first device cannot receive LT frame 4 through the second sub-link, then the first device will continue to wait in step D until it enters a timeout state or a quiet state and cannot proceed to the next step A. This leads to the restart of the link training process.

[0196] The second setting method, when the first device is in send_tf state or train_local state, and the control domain in the LT frame is the second control domain mentioned above, the link parameter setting process includes the following steps E to G.

[0197] In step E, the first device sends LT frame 5 to the second device. In LT frame 5, the initial condition request bit indicates individual coefficient control, and the values ​​of the coefficient select bit and coefficient request bit are set according to actual needs.

[0198] Step F: The first device waits until it receives LT frame 6 from the second device, then executes step G. In LT frame 6, the coefficient status bit indicates "not updated," and the coefficient select echo bit and coefficient select bit (i.e., the coefficient select bit in LT frame 5) request the parameter. The first device waits for LT frame 6 from the second device, meaning it waits for the second device to UPDATE_C(k) and then returns a state where coef_sts != "not updated," where != indicates not equal to. The second device's UPDATE_C(k) means that the second device updates the value of C(k) based on variable k (i.e., the equalizer parameter indicated by the value of the coefficient select bit in LT frame 5) and the current value of coef_req (i.e., the value of the coefficient request bit in LT frame 5). The update result is stored in coef_sts (i.e., the coefficient status bit in LT frame 6). coef_sts is an enumerated variable. The values ​​of coef_sts include one of the following: coefficient at limit and equalization limit, equalization limit, coefficient not supported, coefficient at limit, updated, or not updated.

[0199] In step G, the first device sends LT frame 7 to the second device. In LT frame 7, the coefficient request bit indicates hold, and the first device waits until it receives LT frame 8 from the second device. Then, the current link parameter setting process ends, and the device can proceed to the next link parameter setting process, such as proceeding to step E. In LT frame 8, the coefficient status bit indicates not updated.

[0200] If the performance of the second sub-link degrades after the second device sets the link parameters according to LT frame 1, and the first device cannot receive LT frame 6 through the second sub-link, then the first device will continue to wait in step F until it enters the timeout state or the quiet state and will not be able to proceed to step G; or, if the first device cannot receive LT frame 8 through the second sub-link, then the first device will continue to wait in step G until it enters the timeout state or the quiet state and will not be able to proceed to the next step E. This results in the restart of the link training process.

[0201] Therefore, it is evident that the first related technique has a low fault tolerance rate for abnormal situations and is not reliable enough. Once an abnormal situation occurs, it can only wait until it enters the timeout state or quiet state, and then the training_failed state, restarting the link training process. Since restarting the link training process takes a long time (e.g., 12 seconds), the link training process in the first related technique is inefficient.

[0202] In related technology 2, see Figure 12, which shows the state changes of the LT state machine of the first device.

[0203] This related technology 2 is applicable to segmented link training processes. For example, referring to the communication system shown in Figure 3, the segmented link training process includes, but is not limited to: the training process of a link between host chip 1 and the oDSP optical module, the training process of a link between the oDSP optical module and the LPO optical module, and the training process of a link between the LPO optical module and the host chip 2. The embodiments of this application do not limit the order of the training processes for each link segment. Examples of the first devices on each link segment have been given in the description corresponding to Figure 2 above, and will not be repeated here.

[0204] The state machine of the first device enters the quiet state, and correspondingly, the state machines of all other devices on each link segment, except the first device, also enter the quiet state. That is, the segmented link training process begins when the state machines of all devices on each link segment enter the quiet state. Afterwards, the first device enters the send_training state, enabling it to send LT frames to the second device. Thus, the state machine of the first device can enter the train_local and train_remote states. The send_training state corresponds to the send_tf state described above, the train_local state corresponds to the training process of the second sub-link described above, and the train_remote state corresponds to the training process of the first sub-link described above. Here, we will use the train_local state, specifically the training process of the second sub-link, as an example for explanation.

[0205] When the state machine of the first device is in the train_local state, if the first device completes the training process of the second sub-link, the first device enters the segment_ready state, and then can enter the link_ready state, and enter the link_up state according to actual needs to send data.

[0206] If the first device's state machine is in the train_local or segment_ready state, and the first device has not locked a frame (!local_TFL), then the first device's state machine enters the recover state, and the first device starts the recovery timer (recovery_timer).

[0207] If the first device recovers the locked frame (local_TFL) within the recovery_timer timeout period (e.g., 20 to 30 milliseconds), the first device can re-enter the train_local state.

[0208] If the first device fails to recover the locked frame within the recovery_timer's timeout period, the recovery_timer completes (recovery_timer_done), and the first device's state machine exits the recovery state and enters the fail state. Afterward, the first device's state machine needs to re-enter the quiet state and wait for the state machines of all other devices to also enter the quiet state before restarting the segmented link training process.

[0209] The reasons that might cause the state machine of the first device to enter the recover state include: after the first device sends an LT frame to the second device, the second device sets the link parameters according to the LT frame (it should be understood that these link parameters refer to the link parameters associated with the second device's second TX), but these link parameters cause a performance degradation in the second sub-link. Under this abnormal condition, the first device cannot receive signals through the second sub-link and cannot lock the frame. If the first device cannot recover the frame lock within 20 to 30 milliseconds, it will enter the fail state after the frame lock failure period reaches 20 to 30 milliseconds, restarting the segmented link training process.

[0210] Therefore, it is evident that the fault tolerance rate for abnormal situations in related technology two is low. Once an abnormal situation occurs and the frame lock cannot be restored, it is necessary to wait until the system enters a fail state and restart the segmented link training process. Since restarting the segmented link training process takes a long time (e.g., 12 seconds) and begins when the state machines of the devices on each link segment enter a quiet state, the segmented link training process in related technology two is inefficient and has a high overhead.

[0211] As can be seen from the analysis above, both related technologies one and two have low fault tolerance rates for abnormal situations, which reduces the efficiency of the link training process.

[0212] To address this, this application provides a link training method that improves fault tolerance to abnormal situations and enhances the efficiency and reliability of the link training process. Taking the application of this method to a first device as an example, this method can be used to implement the training process of a second sub-link. As shown in Figure 13, the method includes the following steps 1301 and 1302.

[0213] Step 1301: The first device sends a first frame to the second device, the first frame instructing the second device to perform the first link training.

[0214] The first frame instructs the second device to perform first link training, which includes at least one link parameter setting process. Taking one link parameter setting process as an example, referring to Figure 1, the first RX of the first device detects the signal state of the second sub-link, the first LT algorithm module generates the first frame based on the signal state, the first TX sends the first frame to the second RX, the second RX sends the first frame to the second LT algorithm module, and the second LT algorithm module controls the second TX to set the associated link parameters of the second TX (denoted as the first link parameters) based on the first frame. Optionally, the first frame is the LT frame described above.

[0215] For example, when the first device is in send_tf state (send_training state) or train_local state, and the first device implements the link parameter setting process according to the first setting method described above, the first frame is LT frame 1 in step A above.

[0216] For example, when the first device is in send_tf state (send_training state) or train_local state, and the first device implements the link parameter setting process according to the second setting method described above, the first frame is LT frame 5 in step E above.

[0217] Step 1302: In response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, the second frame instructing the second device to perform second link training.

[0218] In this embodiment, when the first device detects an abnormal situation (i.e., the first device fails to recognize the response of the second device or the first device fails to lock a frame), it triggers an interrupt. The first device can then handle the abnormal situation via software or hardware, for example, by sending a second frame to the second device. In software mode, the interrupt can be attached to the MCU interrupt vector table. The MCU responds to and handles the abnormal situation using the interrupt method, achieving a processing delay of less than 2 milliseconds. Exemplarily, the MCU can employ a reduced instruction set computer (RISC) version 5 (V) open-source MCU framework; this embodiment does not limit this approach. In hardware mode, the first device can cache pre-stored commands. Based on these commands, the abnormal situation is handled through a hardware state machine after the interrupt is triggered.

[0219] In this process, after the second device performs the first link training based on the first frame, that is, after the second TX sets the first link parameters based on the first frame, the transmission performance of the second TX may decrease, leading to a decrease in the performance of the second sub-link, i.e., an abnormal situation occurs. The abnormal situation may result in: the first device not recognizing the response of the second device, or the first device not locking the frame.

[0220] The second frame instructs the second device to perform second link training, which includes at least one link parameter setting process. Taking one link parameter setting process as an example, referring to Figure 1, the first RX of the first device detects the signal state of the second sub-link, the first LT algorithm module generates the second frame based on the signal state, the first TX sends the second frame to the second RX, the second RX sends the second frame to the second LT algorithm module, and the second LT algorithm module controls the second TX to set the associated link parameters of the second TX (denoted as the second link parameters) based on the second frame. Optionally, the second frame is the LT frame described above.

[0221] For example, the first device not recognizing the response of the second device includes: because the second device did not send an LT frame to the first device, the first device did not receive the LT frame sent by the second device. For instance, after the second device sets the first link parameters based on the first frame, it is unable to send an LT frame to the first device. For example, if the first frame is LT frame 1 in step A above, the LT frame that the second device cannot send is LT frame 2 in step B above. Or, if the first frame is LT frame 5 in step E above, the LT frame that the second device cannot send is LT frame 6 in step F above.

[0222] Alternatively, the first device may not recognize the response from the second device, including: the second device sending an LT frame to the first device; the first device receiving the LT frame sent by the second device and being able to identify the frame marker position in the received LT frame, but unable to identify the DME field in the received LT frame. For example, due to a high bit error rate in the received LT frame, the first device may have made a decoding error in the DME field, thus failing to identify the DME field.

[0223] As mentioned above, the first device unlocked frame is also known as local_tf_lock being false. For example, the first device unlocked frame includes: a state where local_tf_lock is false, or a state where local_tf_lock is false and lasts for a period of time, such as a period of less than 20 milliseconds. The duration of this period is not limited in this embodiment of the application.

[0224] In this context, `local_tf_lock` being false indicates that the frame marker position of the LT frame cannot be identified. That is, the first device is not locking frames, including situations where the first device cannot identify the frame marker position in the LT frame returned by the second device. For example, after the second device sets the first link parameters based on the first frame, it sends an LT frame to the first device according to the set first link parameters. However, due to a performance degradation in the second sub-link, the first device cannot identify the frame marker position in the received LT frame (i.e., the LT frame returned by the second device). Examples of such LT frames can be found in the explanation above and will not be repeated here.

[0225] In some implementations, before the first device sends a second frame to the second device in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the method further includes: the first device sending a third frame to the second device. That is, after the first device sends a first frame to the second device, it first sends a third frame to the second device, and then sends a second frame to the second device. For example, the third frame is an LT frame.

[0226] For example, the third frame includes a training type and the training type indicates individual parameter control. Referring to Table 1 above, the training type indicating individual parameter control included in the third frame can mean that the value of the initial condition request (ic_req) bit in the third frame is 000, indicating individual coefficient control (ic_req = ind_ctl). For example, when the first device implements the link parameter setting process according to the first setting method described above, the control domain in the first frame is the first control domain described above, and the third frame can be LT frame 3 in step C, or the third frame can be another LT frame different from LT frame 3, as long as the value of the initial condition request bit in the third frame is 000.

[0227] Referring to Figure 14, the second device performs the first link training based on the first frame, and the state machine of the second device enters the new initial condition (new_IC) state. The third frame is used to break the new_IC state, or in other words, the third frame is used to prevent the state machine of the second device from remaining in the new_IC state (i.e., deadlock). Deadlock refers to a situation where the first device fails to recognize the response of the second device or fails to lock a frame, preventing it from sending a new LT frame to the second device. Consequently, the second device continues to wait for the first device to send a new LT frame, causing its state machine to remain in a certain state (such as the new_IC state mentioned above), thus triggering a timeout and restarting the link training process. In this embodiment, the third frame can prevent the state machine of the second device from deadlocking in the new_IC state. That is, when the second device receives the third frame, since the third frame satisfies ic_req = ind_ctl, the state machine of the second device can enter the new index state. Therefore, when the second device receives the second frame, it can perform the second link training according to the second frame, and the state machine of the second device will jump from the new_index state to the state corresponding to the second link training. For example, the state corresponding to the second link training is another new_IC state or another new_request state.

[0228] For example, the third frame may include a hold request or the training parameters included in the third frame may differ from those included in the first frame. Referring to Table 1 above, a hold request in the third frame could mean that the coefficient request bit (coef_req) in the third frame is 00, indicating hold (coef_req = hold). The training parameters included in the third frame being different from those included in the first frame (i.e., link parameter k) could mean that the value of the coefficient select bit in the third frame is different from the value of the coefficient select bit in the first frame (coef_sel ≠ k). For instance, when the first device implements the link parameter setting process according to the second setting method described above, the control domain in the first frame is the second control domain described above, and the third frame can be LT frame 7 in step G, or it can be any other LT frame different from LT frame 7, as long as the value of the coefficient request bit in the third frame is 00 or coef_sel ≠ k.

[0229] Referring to Figure 15, the second device performs first link training based on the first frame, and its state machine enters the new_request state. The third frame is used to break the new_request state; in other words, the third frame is used to prevent the second device's state machine from remaining in the new_request state. Therefore, when the second device receives the third frame, if the third frame satisfies coef_req = hold, or if the third frame satisfies coef_sel ≠ k, then the second device's state machine can enter the wait state. Thus, when the second device subsequently receives the second frame, it can perform second link training based on the second frame.

[0230] In other embodiments, after the first device sends the first frame to the second device, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device directly sends the second frame to the second device. The first device directly sending the second frame to the second device may mean that the aforementioned third frame has not been sent before the first device sends the second frame to the second device.

[0231] For example, if the first frame includes the first type of control domain mentioned above, the second device performs first link training based on the first frame, and the state machine of the second device enters the new_IC state. After the second device receives the second frame, the second device performs second link training based on the second frame, and the state machine of the second device can sequentially jump from the new_IC state to the new_index state and the state corresponding to the second link training. For example, the state corresponding to the second link training is another new_IC state or another new_request state.

[0232] For example, if the first frame includes the second type of control domain mentioned above, the second device performs first link training based on the first frame, and the state machine of the second device enters the new_request state. After the second device receives the second frame, the second device performs second link training based on the second frame, and the state machine of the second device can jump from the new_request state to the wait state and the state corresponding to the second link training in sequence. For example, the state corresponding to the second link training is another new_IC state or another new_request state.

[0233] In this embodiment, when an abnormal situation causes the first device to fail to recognize the response of the second device or the first device to fail to lock a frame, the first device can send a second frame to the second device, and the second frame instructs the second device to perform the training of the second link. Therefore, in abnormal situations, the first device will not directly enter the timeout state / quiet state / recover state due to continuous waiting, avoiding the direct restart of the training process of the second sub-link, that is, avoiding the direct restart of the training process of the first sub-link and the training process of the second sub-link. In other words, this embodiment provides a fault tolerance mechanism before directly entering the timeout state / quiet state / recover state. This fault tolerance mechanism means that the first device can send a second frame to the second device in abnormal situations. This fault tolerance mechanism is independent of the timeout state / quiet state / recover state and does not conflict with them. Therefore, the efficiency of implementing the training process of the second sub-link in this embodiment is high, and due to the existence of the fault tolerance mechanism, the training process of the second sub-link has high reliability and compatibility.

[0234] For example, when the first device is in the send_tf state (send_training state) or the train_local state, and the first device implements the link parameter setting process according to the first setting method described above:

[0235] In the first example, if the first device sends LT frame 1 in step A above, then in the event of an abnormal situation, the first device does not need to continue waiting for LT frame 2 according to step B, but can execute step C to send LT frame 3 in step C.

[0236] In the second example, if the first device sends LT frame 3 in step C above, then in the event of an abnormal situation, the first device does not need to continue waiting for LT frame 4 according to step D, but can execute the next step A after step D (for example only).

[0237] For example, when the first device is in the send_tf state (send_training state) or train_local state, and the first device implements the link parameter setting process according to the second setting method described above:

[0238] In the third example, if the first device sends the LT frame 5 in step E above, then in the event of an abnormal situation, the first device does not need to continue waiting for the LT frame 6 according to step F, but can execute step G to send the LT frame 7 in step G.

[0239] In the fourth example, if the first device sends the LT frame 7 in step G above, then in the event of an abnormal situation, the first device does not need to continue waiting for the LT frame 8 according to step G, but can execute the next step E of step G (for example only).

[0240] In an exemplary embodiment, the first device does not recognize the response of the second device, including but not limited to the following implementation methods.

[0241] In the first implementation, the first device not recognizing the response of the second device includes: the first device not recognizing the response of the second device within a first duration after sending the first frame, for example, the first device not receiving the LT frame sent by the second device within the first duration after sending the first frame. The first duration is less than the timeout duration of max_wait_timer during link training (e.g., 12 seconds), and the timeout duration of max_wait_timer is also the timeout duration of the timeout state.

[0242] The first device can start a first timer after sending the first frame. The first timer stops and resets upon receiving a response from the second device. If the first timer reaches a first duration, it indicates that the first device did not receive a response from the second device within the first duration after sending the first frame; therefore, the first device sends a second frame to the second device. Since the first duration is less than the timeout duration of `max_wait_timer`, this avoids the first device's state machine entering a timeout state, which would otherwise cause the link training to restart.

[0243] In the second implementation, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, and the first duration is less than the timeout duration of the quiet state.

[0244] The first device can start a second timer after sending the first frame. The second timer stops and resets upon detecting a response from the second device. If the second timer reaches a first duration, it indicates that the first device did not detect a response from the second device within the first duration after sending the first frame, and therefore the first device sends a second frame to the second device. Since the first duration is less than the timeout duration of the quiet state (e.g., 20 milliseconds), the process of restarting the link training due to the first device's state machine entering the quiet state is avoided.

[0245] In the third implementation, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, and the first duration is less than the timeout duration of the recovery state, that is, the timeout duration of the recovery_timer described above.

[0246] The first device can start a third timer after sending the first frame. The third timer stops and resets upon detecting a response from the second device. If the third timer reaches a first duration, it indicates that the first device did not detect a response from the second device within the first duration after sending the first frame. Therefore, the first device sends a second frame to the second device. Since the first duration is less than the timeout duration of the recover state (e.g., 20 to 30 milliseconds), the process of restarting the link training due to the first device's state machine entering the recover state is avoided.

[0247] The first timer, second timer, and third timer mentioned above can be the same timer or different timers; this application embodiment does not limit this. In this application embodiment, the first duration can be less than the minimum value among the timeout duration of the timeout state, the timeout duration of the quiet state, and the timeout duration of the recover state, and this minimum value is, for example, 20 milliseconds. Accordingly, the first device not recognizing the response of the second device includes: the first device not recognizing the response of the second device within 20 milliseconds after sending the first frame.

[0248] For example, the first duration is also greater than a threshold value, which is the sum of the response delay and the path delay. The response delay is the time it takes for the second device to perform the first link training based on the first frame. For example, in a 106G scenario, the response delay is 314 nanoseconds. The path delay is the bidirectional transmission delay between the first and second devices. For example, in a 10-kilometer fiber optic scenario, the path delay is 100 microseconds. Considering both the response delay and the path delay, the threshold value in this embodiment can be 2 milliseconds. Since the first duration is greater than the threshold value, the first duration can be 3 to 5 milliseconds. That is, when the first device detects that the response of the second device is not recognized, it can stop waiting after waiting for 3 to 5 milliseconds and send a second frame to the second device.

[0249] For example, in the first example above, the first frame is LT frame 1 in step A. If the first device does not recognize LT frame 2 within 3 to 5 milliseconds after sending the first frame, the first device will no longer wait for LT frame 2 according to step B, but will instead execute step C to send the second frame to the second device. Examples two through four above will not be elaborated further here.

[0250] In an exemplary embodiment, the first device is not frame-locked, including but not limited to the following implementation methods.

[0251] In the first implementation, the first device does not lock the frame, including: the first device does not lock the frame for a second period of time after sending the first frame. For example, the first device fails to identify the frame marker position of the LT frame sent by the second device within the second period of time after sending the first frame. The second period is less than the timeout duration of max_wait_timer during link training (e.g., 12 seconds), and the timeout duration of max_wait_timer is also the timeout duration of the timeout state.

[0252] The first device can start a fourth timer after sending the first frame. The fourth timer stops counting and resets after the frame is locked. If the fourth timer reaches the second duration, it means that the first device did not lock the frame within the second duration after sending the first frame, so the first device sends the second frame to the second device. Since the second duration is less than the timeout duration of max_wait_timer, the process of restarting the link training caused by the first device's state machine entering the timeout state is avoided.

[0253] In the second implementation, the first device does not lock the frame, including: the first device does not lock the frame for a second period of time after sending the first frame, and the second period of time is less than the timeout period of the quiet state.

[0254] The first device can start a fifth timer after sending the first frame. The fifth timer stops counting and resets after the frame is locked. If the fifth timer reaches the second duration, it means that the first device did not lock the frame within the second duration after sending the first frame, so the first device sends the second frame to the second device. Since the second duration is less than the timeout duration of the quiet state (e.g., 20 milliseconds), the process of restarting the link training due to the first device's state machine entering the quiet state is avoided.

[0255] In the third implementation, the first device does not lock the frame, including: the first device does not lock the frame for a second duration after sending the first frame, the second duration being less than the timeout duration of the recovery state, that is, the timeout duration of recovery_timer.

[0256] The first device can start a sixth timer after sending the first frame. The sixth timer stops counting and resets after the frame is locked. If the sixth timer reaches the second duration, it means that the first device did not lock the frame within the second duration after sending the first frame, so the first device sends the second frame to the second device. Since the second duration is less than the timeout duration of the recover state (e.g., 20 to 30 milliseconds), the process of restarting the link training due to the first device's state machine entering the recover state is avoided.

[0257] The aforementioned fourth, fifth, and sixth timers can be the same or different timers; this application embodiment does not limit this. In this application embodiment, the second duration can be less than the minimum value among the timeout duration of the timeout state, the timeout duration of the quiet state, and the timeout duration of the recover state, which is, for example, 20 milliseconds. Correspondingly, the first device not locking the frame includes: the first device not locking the frame within 20 milliseconds after sending the first frame. Exemplarily, the second duration is also greater than a threshold value, which has been explained above and will not be repeated here. Exemplarily, the second duration in this application embodiment can be 3 to 5 milliseconds.

[0258] For example, the second duration can be the same as or different from the first duration. If the first duration and the second duration are the same, the first duration and the second duration can be unified as the maximum response waiting time (max_respond_waiting_time), or the timeout duration of the maximum response waiting timer (max_respond_waiting_timer), which can be any of the first timer, second timer, third timer, fourth timer, fifth timer, or sixth timer mentioned above.

[0259] Let `max_respond_waiting_time` be denoted as T1, and the timeout duration for the timeout state / quiet state / recover state be denoted as T2 (T2 > T1). The training process of the second sub-link is illustrated in Figure 16. After the first device sends the first frame to the second device, the second device performs first link training based on the first frame. The second TX of the second device sets the first link parameters, which may cause a performance degradation in the second sub-link, leading to abnormal situations. For the first device, an abnormal situation results in the inability to recognize the response / unlocked frame of the second device. If the waiting time for the first device to recognize the response / locked frame of the second device after sending the first frame does not reach T1, the first device continues to wait. If the waiting time reaches T1 but not T2, the first device determines the second link parameters and sends the second frame so that the second device can perform second link training based on the second frame. The second TX of the second device sets the second link parameters to avoid restarting the link training process. If the waiting time reaches T2, the first device can restart the link training process.

[0260] For example, the process of the first device sending the second frame can be repeated multiple times. The second link parameters set for the second link training indicated by each second frame can be different or the same. For example, if T1 is 5 milliseconds and T2 is 20 milliseconds, the first device can send the second frame 4 times before restarting the link training process. If the first device can recognize the response / lock frame of the second device within T1 after sending the second frame, the process of restarting the link training can be avoided.

[0261] The training process of the second sub-link provided in this application embodiment is compatible with LT frames (LT frames as shown in Figure 11) and LT state machines (LT state machines as shown in Figures 10 and 12). For example, the training process of the second sub-link provided in this application embodiment can be deployed in at least one of the send_tf state or train_local state of the LT state machine shown in Figure 10 (but is not limited thereto), and can also be deployed in at least one of the send_training state, train_local state, train_remote state or segment_ready state of the LT state machine shown in Figure 12 (but is not limited thereto).

[0262] In an exemplary embodiment, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, including: in response to the first device not recognizing the second device, or in response to the first device not locking a frame, without entering the initialization state or silent state of the state machine of the first device, the first device directly sends a second frame to the second device.

[0263] Optionally, not entering the initialization state of the first device's state machine can mean not entering the initialize state in the LT state machine shown in Figure 10. Alternatively, not entering the quiet state of the first device's state machine can mean not entering the quiet state in the LT state machine shown in Figure 12.

[0264] For example, the first device can send the second frame directly to the second device. This can be done either by sending the second frame immediately after generating it, or by waiting for a certain period of time after generating it before sending it to the second device. This embodiment does not limit the duration of this "certain period," as long as it ensures that waiting for this period does not lead to the first device entering its initialization or silent state.

[0265] In an exemplary embodiment, the second frame instructs the second device to interrupt the first link training and perform second link training. Exemplarily, the second frame includes a first subframe and a second subframe, where the first subframe instructs the second device to interrupt the first link training, and the second subframe instructs the second device to perform second link training. For example, the first subframe is an LT frame, and the second subframe is another LT frame. Alternatively, the first and second subframes may be the same LT frame, where the first subframe contains one or more bits from that LT frame, and the second subframe contains one or more bits from that LT frame that are different from the first subframe.

[0266] For example, the second frame instructs the second device to interrupt the first link training and perform the second link training, and there are at least three different implementations of this.

[0267] In the first implementation, the second frame includes a preset request, which is used to trigger the second device to perform the second link training.

[0268] As mentioned earlier, the first link training includes at least one link parameter setting process. After each link parameter setting process, a training state is obtained. Therefore, the first link training includes at least one training state, and each training state corresponds to a link parameter group. Each link parameter group includes at least one link parameter, and the at least one link parameter included in each link parameter group can be the first link parameter described above. Wherein, when a link parameter group includes one link parameter, the link parameter space is a one-dimensional space. When a link parameter group includes two link parameters, the link parameter space is a two-dimensional space. When a link parameter group includes three or more link parameters, the link parameter space is a multi-dimensional space.

[0269] Before the second device performs the first link training, there exists a historical training state prior to the first link training. After the second device performs the first link training, there are other training states besides the historical training states. The last of these other training states is the current training state of the first link training. For example, the first link training includes a first link parameter setting process and a second link parameter setting process. After the second device performs the first link parameter setting process, the first training state is obtained; after performing the second link parameter setting process, the second training state is obtained. Therefore, the other training states include the first training state and the second training state, with the second training state being the current training state of the first link.

[0270] For example, the second frame includes an initial condition request bit, which indicates that the link parameters are set according to the preset. For instance, referring to Table 1, the value of the initial condition request bit in the second frame can be one of the following: 111, 101, 011, 001, 110, 100, 010, or 010, etc.

[0271] Based on this, the second device performs second link training, including: rolling back from the current training state of the first link training to the training state corresponding to the preset request. The link parameter group corresponding to the training state corresponding to the preset request includes the link parameters set according to the preset. Optionally, the rollback from the current training state of the first link training to the training state corresponding to the preset request can be performed according to the first setting method described above. In this embodiment, the rollback from the current training state of the first link training to the training state corresponding to the preset request can be performed in one go.

[0272] Taking a link parameter group consisting of two link parameters, c(-1) and c(1) as an example, and referring to Figure 17, we can illustrate this further. In Figure 17, the horizontal axis X represents c(-1), and the vertical axis Y represents c(1). Each cell represents a link parameter group. To facilitate the differentiation of different link parameter groups, each link parameter group corresponds to a coordinate. For example, coordinate (1, 1) corresponds to a link parameter group in the first column of the first row in Figure 17. Another example is coordinate (2, 1), which corresponds to a link parameter group in the second column of the first row in Figure 17.

[0273] Additionally, the number in each cell represents the performance of the second sub-link when the second TX of the second device sets this link parameter group. The performance of the second sub-link can be reflected by the signal status (SNR, BER, or eye diagram) described above. A number of 0 indicates poor performance of the second sub-link, which may result in the aforementioned abnormal situation (also known as a performance hole), causing the first device to fail to recognize the response of the second device, or the first device to be unable to lock frames. A number of 1 indicates poor performance of the second sub-link; although the aforementioned abnormal situation will not occur, it is a performance boundary point, and correspondingly, the link parameter group is also a boundary point of the link parameter space. A number greater than 1 indicates normal performance of the second sub-link, and the aforementioned abnormal situation will not occur; the larger the number, the better the performance of the second sub-link.

[0274] In one example, when the second device has not performed the first link training, the preset training state corresponds to the link parameter set at coordinates (1, 9). The first link training includes a link parameter setting process. After the second device performs this link parameter setting process, the current training state is obtained, and the current training state corresponds to the link parameter set at coordinates (2, 9). That is, c(-1) was increased during this link parameter setting process, and the adjustment direction is the direction of increasing the value of c(-1).

[0275] In order to rollback from the current training state of the first link to the training state corresponding to the preset request, the link parameter group at coordinates (2, 9) needs to be adjusted to the link parameter group at coordinates (1, 9). In the case of using the first setting method, the first request information included in the second frame is the initial condition request bit, and the preset indicated by the initial condition request bit is the link parameter group at coordinates (1, 9).

[0276] In the second implementation, the second frame includes first request information, which is used to request the second device to perform second link training based on the historical training state before the first link training.

[0277] The second device performs second-link training based on the historical training state prior to the first-link training. This includes: rolling back from the current training state of the first-link training to a first updated training state. The first updated training state is determined based on the historical training state and can be different from or the same as the historical training state. The current training state and historical training state of the first-link training have been described in the first implementation method and will not be repeated here.

[0278] In some implementations, the first request information included in the second frame is an initial condition request bit, which allows the first setup described above to rollback from the current training state of the first link training to the first updated training state. Here, the preset indicated by the initial condition request bit is the link parameter group corresponding to the first updated training state. In this implementation, the current training state of the first link training can be rolled back to the initial training state in one go.

[0279] In other embodiments, the first request information included in the second frame consists of a coefficient select bit and a coefficient request bit. This allows for a rollback from the current training state of the first link training to the first updated training state, as described in the second setting above. For example, if there is a target link parameter whose value changes in both the link parameter group corresponding to the current training state and the link parameter group corresponding to the first updated training state, the coefficient select bit indicates this target link parameter, and the coefficient request bit indicates the adjustment direction of this target link parameter. This adjustment direction is used to adjust the value of the target link parameter in the link parameter group corresponding to the current training state to the value of the target link parameter in the link parameter group corresponding to the first updated training state. In this embodiment, the rollback from the current training state of the first link training to the first updated training state can be performed once, or multiple times. Whether a single rollback or multiple rollbacks are performed depends on the difference between the first updated training state and the current training state.

[0280] Referring again to Figure 17, in one example, when the second device has not performed the first link training, the historical training state corresponds to the link parameter group at coordinates (3, 8). The first link training includes a link parameter setting process. After the second device performs this link parameter setting process, the current training state is obtained, which corresponds to the link parameter group at coordinates (3, 9). That is, c(1) was increased during this link parameter setting process, and the adjustment direction is the direction of increasing the value of c(1). In addition, the first updated training state determined based on the historical training state can correspond to the link parameter group at coordinates (4, 9), or it can correspond to the link parameter group at coordinates (3, 10), etc.

[0281] Taking the link parameter group corresponding to coordinates (4, 9) in the first updated training state as an example, in order to rollback from the current training state of the first link training to the first updated training state, it is necessary to adjust the link parameter group at coordinates (3, 9) to the link parameter group at coordinates (4, 9). In the first setting method, the first request information included in the second frame is the initial condition request bit, and the preset indicated by the initial condition request bit is the link parameter group at coordinates (4, 9) (this is just an example; the link parameter group represented by the preset can be set according to actual needs or specifications). In the second setting method, the first request information included in the second frame is the coefficient select bit and the coefficient request bit. The target link parameter indicated by the coefficient select bit is c(-1), while the adjustment direction indicated by the coefficient request bit is the direction of increasing the value of c(-1).

[0282] In the third implementation, the second frame includes second request information, which is used to request the second device to perform second link training in the current training state of the first link training.

[0283] The second device performs second-link training in the current training state of the first-link training, including: jumping from the current training state of the first-link training to a second updated training state. In one example, the second updated training state is unrelated to the historical training state. Optionally, the second updated training state is determined based on the current training state of the first-link training.

[0284] In some implementations, the second frame includes an initial condition request bit, which allows the current training state of the first link training to jump to the second updated training state according to the first setting method described above. The preset indicated by the initial condition request bit is the link parameter group corresponding to the second updated training state. In this implementation, the current training state of the first link training can be jumped to the initial training state in one step.

[0285] In other embodiments, the second frame includes a coefficient select bit and a coefficient request bit as the second request information. This allows the jump from the current training state of the first link training to the second updated training state, as described in the second setting method above. For example, in the link parameter group corresponding to the current training state and the link parameter group corresponding to the second updated training state, there exists a target link parameter whose value changes. The coefficient select bit indicates this target link parameter, and the coefficient request bit indicates the adjustment direction of this target link parameter. The adjustment direction is used to adjust the value of the target link parameter in the link parameter group corresponding to the current training state to the value of the target link parameter in the link parameter group corresponding to the second updated training state. In this embodiment, the jump from the current training state of the first link training to the second updated training state can be performed in one go, or multiple times. The choice between a single jump and multiple jumps depends on the difference between the second updated training state and the current training state.

[0286] Referring to Figure 18, in one example, the first link training includes a link parameter setting process. After the second device performs this link parameter setting process, the current training state is obtained, which corresponds to the link parameter set at coordinates (6, 7). Additionally, the second update state corresponds to the link parameter set at coordinates (10, 7).

[0287] To jump from the current training state of the first link training to the second updated training state, the link parameter group at coordinates (6, 7) needs to be adjusted to the link parameter group at coordinates (10, 7). In the first setup method, the second frame includes the initial condition request bit, which indicates the preset of the link parameter group at coordinates (10, 7). In the second setup method, the second frame includes the coefficient select bit and the coefficient request bit. The coefficient select bit indicates the target link parameter c(-1), while the coefficient request bit indicates the adjustment direction of increasing the value of c(-1).

[0288] The bolded portion in Figure 18 shows two different link parameter spaces. As can be seen from the examples above, through the third implementation method, the embodiments of this application can achieve the crossing of different link parameter spaces during the link parameter setting process, which is beneficial to obtaining better link parameters and improving the performance of the second sub-link.

[0289] The above describes three different implementations of the second frame instructing the second device to interrupt the first link training and execute the second link training. It should be understood that during a single link parameter setting process, one of these three implementations can be chosen. However, during multiple link parameter setting processes, these three implementations can be used interchangeably. For example, the first implementation can be used in the first link parameter setting process, the second implementation in the second, and the third implementation in the third. For instance, if the link parameter group corresponding to the current training state of the first link training is a boundary point of the link parameter space, the third implementation is used. In other cases, i.e., if the link parameter group corresponding to the current training state of the first device is not a boundary point of the link parameter space, either the first or second implementation is used.

[0290] For example, when the first device receives an LT frame from the second device, it determines whether the link parameter group corresponding to the current training state is a boundary point of the link parameter space based on the coefficient status indications "coefficient at limit and equalization limit," "equalization limit," or "coefficient at limit" in the LT frame. If so, a jump is performed using the third implementation method. In other words, the coefficient status indications "coefficient at limit and equalization limit," "equalization limit," or "coefficient at limit" in the LT frame can be used to determine whether a jump is needed.

[0291] For example, if the first device determines, based on the first LT algorithm module, that the adjustment of the link parameter set corresponding to the current training state has reached the preset maximum adjustment step count (pre_max_adjust_steps), then the first device determines the link parameter set corresponding to the current training state as the boundary point of the link parameter space. For instance, if the value of pre_max_adjust_steps is 10, and the link parameter set corresponding to the current training state has been obtained after 10 adjustments in one adjustment direction, then it can be determined that pre_max_adjust_steps has been reached.

[0292] Based on the three implementation methods described above, the method for determining the second link parameters by the first device is explained. It should be understood that, for the first implementation method, the second link parameter can be the link parameter group corresponding to the training state corresponding to the preset request (hereinafter referred to as the preset link parameter group). For the second implementation method, the second link parameter can be the link parameter group corresponding to the first updated training state, and the first updated training state is determined based on historical training states. For the third implementation method, the second link parameter can be the link parameter group corresponding to the second updated training state.

[0293] In the first implementation, the first device acquires at least one of the following link parameter groups to determine a preset link parameter group: a normal link parameter group in preset form, or an abnormal link parameter group in preset form.

[0294] The preset form of the normal link parameter set allows the performance of the second sub-link to exceed a performance threshold. If the second device sets the normal link parameter set and responds according to it (e.g., sending an LT frame to the first device), the first device can recognize the response of the second device and lock the frame.

[0295] An abnormal link parameter group in preset form is designed to cause the performance of the second sub-link to fall below a performance threshold. If the second device sets the abnormal link parameter group and responds accordingly, the first device will be unable to recognize the second device's response or will be unable to lock the frame.

[0296] For example, the first device can: determine the normal link parameter set in preset form as the preset link parameter set.

[0297] Alternatively, the first device may also: identify other link parameter groups that are different from the abnormal link parameter groups in the preset form as preset link parameter groups.

[0298] Alternatively, the first device may also: calculate a preset link parameter set according to a certain calculation method based on the normal link parameter set in preset form and the abnormal link parameter set in preset form. The calculation method is not limited in the embodiments of this application.

[0299] In the second implementation, the first device acquires at least one link parameter group (i.e., the link parameter group corresponding to the historical training state) from the normal link parameter group or the abnormal link parameter group to determine the link parameter group corresponding to the first updated training state.

[0300] Normal link parameter sets include: normal link parameter sets in the form of preset, and normal link parameter sets in the form of coefficient select & coefficient request. Both of these forms can make the performance of the second sub-link exceed the performance threshold.

[0301] Abnormal link parameter groups include: abnormal link parameter groups in the form of preset, and abnormal link parameter groups in the form of coefficient select & coefficient request. Both of these forms can cause the performance of the second sub-link to fall below the performance threshold.

[0302] In this embodiment, the number of the at least one link parameter group is not limited; it can be set according to actual needs. For example, the at least one link parameter group can be the most recently set normal link parameter group (regardless of its form) or the most recently set abnormal link parameter group (regardless of its form).

[0303] For example, the first device can: use the normal link parameter set as the link parameter set corresponding to the first updated training state, or in other words, use the link parameter set corresponding to the first updated training state as the normal link parameter set.

[0304] Alternatively, the first device can also: determine the target link parameter and the first adjustment direction relative to the previous link parameter group of the normal link parameter group. For example, if the first adjustment direction is the direction of increasing the value of the target link parameter, it means that the correct link parameter adjustment direction is the direction of increasing the value of the target link parameter. Therefore, the value of the target link parameter can continue to be adjusted according to the first adjustment direction to obtain the link parameter group corresponding to the first updated training state.

[0305] Alternatively, the first device may: use other link parameter groups besides the abnormal link parameter group as the link parameter group corresponding to the first updated training state, or in other words, the link parameter group corresponding to the first updated training state is the link parameters included in other link parameter groups besides the abnormal link parameter group.

[0306] Alternatively, the first device can also: determine the target link parameter and the second adjustment direction relative to the link parameter group preceding the abnormal link parameter group. For example, if the second adjustment direction is the direction of increasing the target link parameter value, it means that the incorrect link parameter adjustment direction is the direction of increasing the target link parameter value, while the correct link parameter adjustment direction is the direction of decreasing the target link parameter value. Therefore, the target link parameter value can be adjusted in the opposite direction of the second adjustment direction to obtain the link parameter group corresponding to the first updated training state.

[0307] Alternatively, the first device can: combine the first and second adjustment directions described above to determine the third adjustment direction, and adjust the value of the target link parameter according to the third adjustment direction to obtain the second link parameter.

[0308] Alternatively, the first device can also: select other link parameters based on the target link parameters, adjust the other link parameters in a certain adjustment direction, and obtain the second link parameters.

[0309] For example, the first device can store the aforementioned link parameter sets in a cache, query the cache as needed, and determine a preset link parameter set based on the query result, or determine the link parameter set corresponding to the first updated training state. The cache is also called a request command cache (request_cmd_buff) structure.

[0310] Optionally, referring to Figure 19, the at least one link parameter group mentioned above can be a link parameter group preset based on experience (hereinafter referred to as the first link parameter group), which can be stored in the cache before the link training begins. If the first device has not instructed the second device to set this type of link parameter group via an LT frame, this type of link parameter group can be stored in the cache in advance. Alternatively, the at least one link parameter group mentioned above is a link parameter group set by the first device through an LT frame (hereinafter referred to as the second link parameter group), which can be stored in the cache as the link training process progresses. For example, after the first device sends a frame to the second device, if the frame triggers an abnormal situation (the first device cannot recognize a response or the first device does not lock the frame, triggering a rollback or jump), the link parameter group set in that frame is recorded as an abnormal link parameter group in the cache. If the frame does not trigger an abnormal situation, the link parameter group set in that frame is recorded as a normal link parameter group in the cache. That is, the first device can update the contents stored in the cache during the link training process to ensure the real-time performance of the cache.

[0311] For example, in addition to storing the link parameter groups mentioned above, the cache may also include the following information according to actual needs. The link parameter groups mentioned above are basic information, and the following information are extended information.

[0312] The first piece of information is the sequence code for each link parameter group.

[0313] The first device can sort at least one group of link parameters, with each group corresponding to a serial number. The first type of link parameter group can use a default serial number, while the second type can have its serial number determined based on the setting time. The earlier the setting time, the smaller the serial number and the earlier the order. Conversely, the later the setting time, the larger the serial number and the later the order.

[0314] The second piece of information, the reference identifier, is used to distinguish between normal link parameter groups and abnormal link parameter groups.

[0315] The normal link parameter group corresponds to the first reference identifier, and the abnormal link parameter group corresponds to the second reference identifier. The second reference identifier is different from the first reference identifier, so as to distinguish between the normal link parameter group and the abnormal link parameter group.

[0316] Of course, using reference identifiers to distinguish between normal and abnormal link parameter groups is just one example. In addition, the first device can also distinguish between normal and abnormal link parameter groups by storage location. For example, the cache includes a first storage space and a second storage space; the first storage space stores normal link parameter groups, and the second storage space stores abnormal link parameter groups. Alternatively, the first device can also distinguish between normal and abnormal link parameter groups by serial number. For example, link parameter groups with serial numbers 1-5 in the cache can be designated as normal link parameter groups, and link parameter groups with serial numbers 6-10 as abnormal link parameter groups.

[0317] Taking other information including normal link parameter groups, abnormal link parameter groups, sequence numbers, and reference identifiers as examples, the cached content can be represented as shown in Table 3 below. In Table 3, for example, preset[x], preset[y], and preset[z] are the first type of link parameter groups, and coefficient select[m] & coefficient request[a] and coefficient select[n] & coefficient request[b] are the second type of link parameter groups. N is the first reference identifier corresponding to the normal link parameter group, and Y is the second reference identifier corresponding to the abnormal link parameter group.

[0318] Table 3

[0319] The third piece of information is the setting time of the link parameter group.

[0320] For the first type of link parameter group, the setting time can be the default time. For the second type of link parameter group, the setting time can be the time when the first device sends an LT frame to the second device to indicate the setting of the second type of link parameter group. For example, the setting time can be a timestamp.

[0321] The fourth piece of information is the response of the second device to the link parameter set.

[0322] For normal link parameter groups, since the first device can recognize the response of the second device and lock frames, the content of the second device's response to the normal link parameter group can be determined, such as the content of the LT frame sent by the second device. For abnormal link parameter groups, although the first device cannot recognize the response of the second device or cannot lock frames, this situation itself is a special response event, and therefore this special response event can be used as the content of the second device's response to the abnormal link parameter group.

[0323] The fifth piece of information is the equalization parameters of the first RX of the first device. The equalization parameters have corresponding signal states, such as SNR, BER, or eye diagram, etc.

[0324] Regardless of whether it's a normal or abnormal link parameter group, there are equalization parameters and corresponding signal states. Based on the fifth piece of information, the first device can determine the second link parameters more flexibly. For example, the better the signal state corresponding to the equalization parameters of a link parameter group, the better the performance that link parameter group can provide for the second sub-link. Therefore, the second link parameters can be determined based on that link parameter group first.

[0325] The sixth piece of information is the reference duration, which represents the duration for the first device to recognize the response of the second device, or the duration for the first device to lock a frame.

[0326] For normal link parameter sets, since the first device can recognize the response of the second device and lock frames, the reference duration is the actual duration for which the first device recognizes the response of the second device, or the actual duration for which the first device locks frames. For abnormal link parameter sets, since the first device cannot recognize the response of the second device or cannot lock frames, the reference duration can be a default duration, such as the first duration or the second duration mentioned above. Based on the information in item six, the first device can determine the second link parameters more flexibly. For example, the smaller the reference duration corresponding to a link parameter set, the better the performance of the link parameter set can provide for the second sub-link, and therefore the second link parameters can be determined based on the link parameter set first.

[0327] For example, instead of directly storing the third and sixth pieces of information, the cache may store the difference between the third and sixth pieces of information.

[0328] The seventh piece of information is the verification information.

[0329] This verification information is used to verify information in the cached content other than the verification information itself, in order to ensure the reliability of the information. Optionally, the information in the cached content other than the verification information itself includes: normal link parameter group, abnormal link parameter group, and the first to sixth information items.

[0330] In an exemplary embodiment, the cached content can be information at the granularity of transmission lanes. For example, if the second sub-link includes multiple lanes, the first device can store the corresponding information for each lane separately. Optionally, during the segmented link training process, the devices on each link segment can store the information after the initial link establishment, in order to save time during the subsequent link re-establishment process.

[0331] In the third implementation, the first device does not need to obtain the normal or abnormal link parameter sets mentioned above; instead, it can directly determine the link parameter set corresponding to the second updated training state. For example, the first device randomly determines the link parameter set corresponding to the second updated training state. In one example, the link parameter set corresponding to the second updated training state may be different from the link parameter set corresponding to the current training state of the first link training. This determination method is relatively simple, easy to implement, and has strong applicability.

[0332] This application also provides a link training method, which can be applied to a second device and can be used to implement the training process of a second sub-link. As shown in Figure 20, the method includes the following step 2001.

[0333] Step 2001: When the state machine of the second device is in a new initial condition state or a new request state, in response to receiving the second frame from the first device, the second device performs second link training.

[0334] The new initial condition state is the aforementioned `new_IC` state, and the new request state is the aforementioned `new_request` state. After the second device receives the first frame sent by the first device, if the first frame includes a first type of control field (used to set multiple link parameters), the state machine of the second device enters the `new_IC` state; if the first frame includes a second type of control field (used to set one link parameter), the state machine of the second device enters the `new_request` state. This allows the state machine of the second device to be in either the `new_IC` or `new_request` state. Therefore, when the state machine of the second device is in either the `new_IC` or `new_request` state, it indicates that the second device has received the first frame, and the second device can perform first link training based on the first frame. In this case, in response to receiving the second frame sent by the first device, the second device can perform second link training based on the second frame, and the state machine of the second device can transition from the current `new_IC` state to other states, or from the current `new_request` state to other states. To facilitate the distinction between different states, the new_IC state of the second device's state machine after receiving the first frame is denoted as the first new_IC state, and the new_request state of the second device's state machine after receiving the first frame is denoted as the first new_request state.

[0335] In an exemplary embodiment, the state machine transitions of the second device include, but are not limited to, the following transition scenarios.

[0336] In the first transition scenario, when the state machine of the second device is in the new request state (i.e., the first new_request state), in response to the following condition, the state machine of the second device transitions from the new request state to another new initial condition state (denoted as the second new_IC state): the second frame includes the second training type, which indicates non-individual coefficient control (ind_ctl).

[0337] In the first jump scenario, the first frame is used to set one link parameter, and the second frame is used to set multiple link parameters. The second training type included in the second frame refers to the initial condition request (ic_req) bit in the second frame. See Table 1. The second training type indicates that non-individual parameter control means that the value of the initial condition request bit is other than 000. For example, the value of the initial condition request bit can include one of the following: 111, 101, 011, 001, 110, 100, or 010.

[0338] The second frame includes the second training type, which indicates that the non-individual parameter control is represented as: ic_req≠ind_ctl. This first jump case further includes the following two implementation methods.

[0339] In the first implementation, as shown in Figure 21, in response to satisfying one of the following three conditions, the state machine of the second device transitions from the first new_request state to the wait state, and then from the wait state to the second new_IC state. In the various figures (Figures 14, 15, 21 to 23) of the LT state machine of the second device, + represents "or" and * represents "and".

[0340] Condition 1: ic_req ≠ ind_ctl.

[0341] Condition 2, coef_sel ≠ k, means the training parameters included in the second frame are different from the training parameter k included in the first frame. The training parameters included in the second frame refer to the link parameters indicated by the coefficient select (coef_sel) bit in the second frame, while the training parameters included in the first frame refer to the link parameter k indicated by the coefficient select bit in the first frame. For example, referring to Table 1, the value of the coefficient select bit in the second frame is 100, and the value of the coefficient select bit in the first frame is one of the following: 101, 110, 111, 000, or 001, etc.

[0342] Condition 3, coef_req = hold. That is, the second frame includes a hold request. In other words, as shown in Table 1, the value of the coefficient request (coef_req) bit in the second frame is 00, indicating hold. Therefore, the coefficient request is a hold request.

[0343] The second implementation, as shown in Figure 22, responds to the condition that ic_req≠ind_ctl, the state machine of the second device directly jumps from the first new_request state to the second new_IC state without going through the wait state.

[0344] In the second transition scenario, when the state machine of the second device is in a new initial condition state (i.e., the first new_IC state), in response to the following condition being met, the state machine of the second device transitions from the new initial condition state to another new initial condition state (i.e., the second new_IC state): the second frame includes a second training type, the second training type indicates non-individual parameter control and indicates a second preset mode, the second preset mode is different from the first preset mode indicated by the first training type included in the first frame, the first frame is a frame received by the second device from the first device, the first frame indicates that the second device performs the first link training.

[0345] In the second transition scenario, the first frame is used to set multiple link parameters, and the second frame is used to set multiple link parameters. For example, referring to Figure 23, the transition from one new initial condition state to another new initial condition state in the state machine of the second device can mean that the state machine of the second device directly transitions from the first new_IC state to the second new_IC state without passing through other states.

[0346] The second training type indicates that the parameter control is not individual (represented as condition 4: ic_req ≠ ind_ctl), that is, the value of the initial condition request bit in the second frame is other than 000. For example, the value of the initial condition request bit can include one of the following: 111, 101, 011, 001, 110, 100 or 010, etc.

[0347] The second training type indicates the second preset mode and the second preset mode is different from the first preset mode (represented as condition 5: ic_req≠prev_ic_req, prev_ic_req is the first preset mode). That is, the value of the initial condition request bit in the second frame is different from the value of the initial condition request bit in the first frame. The value of the initial condition request bit in the first frame is also a value other than 000.

[0348] For example, referring to Table 1, the value of the initial condition request bit in the second frame is 001, which means that the equalizer parameters of the second TX of the second device are set according to preset 4. The value of the initial condition request bit in the first frame is 110, which means that the equalizer parameters of the second TX of the second device are set according to preset 3.

[0349] In some implementations, the state machine of the second device transitions from the first new_IC state to the second new_IC state in response to the satisfaction of only conditions 4 and 5. Alternatively, in other implementations, the state machine of the second device transitions from the first new_IC state to the second new_IC state in response to the satisfaction of conditions 4, 5, and condition 3 described above.

[0350] The third transition scenario, step 2001, includes: when the state machine of the second device is in a new initial condition state (i.e., the first new_IC state), in response to receiving a third frame from the first device, the state machine of the second device transitions from the first new_IC state to a new index state (i.e., the new_index state), wherein the third frame includes a training type and the training type indicates individual parameter control; when the state machine of the second device is in the new index state, in response to receiving a second frame, the second device performs second link training.

[0351] The third type of redirection can be found in the explanation corresponding to Figure 14 above, and will not be elaborated here.

[0352] The fourth transition scenario, step 2001, includes: when the state machine of the second device is in the new request state (i.e., the first new_request state), in response to receiving the third frame from the first device, the state machine of the second device transitions from the first new_request state to the waiting state, wherein the third frame includes a hold request or the training parameters included in the third frame are different from the training parameters included in the first frame; when the state machine of the second device is in the waiting state, in response to receiving the second frame, the second device performs second link training.

[0353] The fourth type of jump can be found in the explanation corresponding to Figure 15 above, and will not be elaborated here.

[0354] In an exemplary embodiment, the second device performs second link training, including: the second device interrupts the first link training according to the second frame and performs second link training. Exemplarily, the second device interrupting the first link training according to the second frame and performing second link training includes, but is not limited to, the following three implementation methods.

[0355] In the first implementation, the second frame includes first request information. The second device interrupts the first link training according to the second frame and performs second link training, including: the second device resets the first link training according to the first request information and performs second link training.

[0356] The first implementation method here can be found in the first implementation method described in step 1302.

[0357] In the second implementation, the second frame includes second request information. The second device interrupts the first link training according to the second frame and performs second link training, including: the second device performs second link training based on the historical training state before the first link training according to the second request information.

[0358] The second implementation method here can be found in the second implementation method described in step 1302.

[0359] The third implementation method includes a second frame containing a third request information. The second device interrupts the first link training based on the second frame and executes the second link training, including: the second device executes the second link training based on the third request information in the current training state of the first link training.

[0360] The third implementation method here can be found in the third implementation method described in step 1302.

[0361] The link training method provided by the embodiments of this application has been described above. Corresponding to the above method, the embodiments of this application also provide a link training apparatus. This apparatus is applied to a first device. The apparatus is used to execute the method shown in FIG13 through the various modules shown in FIG24. As shown in FIG24, the link training apparatus provided by the embodiments of this application includes the following modules.

[0362] The transmitting module 2401 is used for the first device to send a first frame to the second device, wherein the first frame instructs the second device to perform the first link training;

[0363] The sending module 2401 is also configured to, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, send a second frame to the second device, the second frame instructing the second device to perform second link training.

[0364] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the maximum wait timer during link training.

[0365] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the silent state.

[0366] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the recovery state.

[0367] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within 20 milliseconds after sending the first frame.

[0368] In some possible implementations, the first device is not frame-locked, including: the first device is not frame-locked within 20 milliseconds after transmitting the first frame.

[0369] In some possible implementations, the sending module 2401 is used to send the second frame directly to the second device in response to the first device not recognizing the second device, or in response to the first device not locking a frame, without entering the initialization state or silent state of the first device's state machine.

[0370] In some possible implementations, the second frame instructs the second device to interrupt the first link training and perform the second link training.

[0371] In some possible implementations, the second frame includes a preset request that triggers the second device to perform second link training.

[0372] In some possible implementations, the second frame includes first request information, which requests the second device to perform second link training based on the historical training state prior to the first link training.

[0373] In some possible implementations, the second frame includes second request information, which requests the second device to perform second link training in the current training state of the first link training.

[0374] In some possible implementations, the sending module 2401 is further configured to: in response to a response that the first device does not recognize the second device, or in response to a response that the first device does not lock a frame, send a third frame to the second device before sending the second frame, the third frame including a training type and the training type indicating individual parameter control, or the third frame including a hold request or the training parameters included in the third frame being different from the training parameters included in the first frame.

[0375] This application also provides another link training apparatus. This apparatus is applied to a second device. The apparatus is used to execute the method shown in FIG20 via the various modules shown in FIG25. As shown in FIG25, the link training apparatus provided in this application includes the following modules.

[0376] The execution module 2501 is used to perform second link training in response to receiving a second frame from the first device when the state machine of the second device is in a new initial condition state or a new request state.

[0377] In some possible implementations, when the state machine of the second device is in a new request state, in response to the following condition being met, the state machine of the second device jumps from the new request state to another new initial condition state: the second frame includes a second training type, which indicates non-individual parameter control.

[0378] In some possible implementations, when the state machine of the second device is in a new initial condition state, in response to the following condition being met, the state machine of the second device jumps from the new initial condition state to another new initial condition state: the second frame includes a second training type, the second training type indicates non-individual parameter control and indicates a second preset mode, the second preset mode is different from the first preset mode indicated by the first training type included in the first frame, the first frame is a frame received by the second device from the first device, the first frame instructs the second device to perform the first link training.

[0379] In some possible implementations, execution module 2501 is configured to, when the state machine of the second device is in a new initial condition state, in response to receiving a third frame from the first device, transition the state machine of the second device from the new initial condition state to a new index state, wherein the third frame includes a training type and the training type indicates individual parameter control; when the state machine of the second device is in a new index state, in response to receiving a second frame, the second device performs second link training.

[0380] In some possible implementations, execution module 2501 is configured to, when the state machine of the second device is in a new request state, in response to receiving a third frame from the first device, transition the state machine of the second device from the new request state to a waiting state, wherein the third frame includes a hold request or the training parameters included in the third frame are different from the training parameters included in the first frame; when the state machine of the second device is in the waiting state, in response to receiving a second frame, the second device performs second link training.

[0381] In some possible implementations, the second frame includes a preset request, and the second device interrupts the first link training according to the second frame and performs the second link training, including: the second device performs the second link training according to the preset request.

[0382] In some possible implementations, the second frame includes first request information, and the second device interrupts the first link training according to the second frame and performs second link training, including: the second device performs second link training based on the historical training state before the first link training according to the first request information.

[0383] In some possible implementations, the second frame includes second request information, and the second device interrupts the first link training according to the second frame and performs second link training, including: the second device performs second link training according to the second request information in the current training state of the first link training.

[0384] It should be understood that the beneficial effects of the devices shown in Figures 24 and 25 in implementing their functions are the same as those of the methods shown in Figures 13 and 20. The devices shown in Figures 24 and 25 are only illustrated with examples of the above-described functional module divisions. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the devices and methods provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the method embodiments, which will not be repeated here.

[0385] This application also provides a communication device, which includes a transceiver and a processor. The transceiver is used to perform transmission and reception functions, and the processor is used to perform other functions besides transmission and reception functions, so that the communication device can implement the link training method shown in FIG13 or FIG20.

[0386] This application embodiment also provides a chip, which includes an interface circuit and a control circuit. The interface circuit is used to transmit and receive data, and the control circuit is used to process the data so that a first device with the chip installed can implement the following link training method, namely the link training method shown in FIG13: the first device sends a first frame to the second device, the first frame instructing the second device to perform first link training; in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, the second frame instructing the second device to perform second link training.

[0387] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the maximum wait timer during link training.

[0388] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the silent state.

[0389] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, the first duration being less than the timeout duration of the recovery state.

[0390] In some possible implementations, the first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within 20 milliseconds after sending the first frame.

[0391] In some possible implementations, the first device is not frame-locked, including: the first device is not frame-locked within 20 milliseconds after transmitting the first frame.

[0392] In some possible implementations, in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, including:

[0393] In response to the first device not recognizing the second device, or in response to the first device not locking a frame, the first device does not enter the initialization state or silent state of its state machine, and directly sends the second frame to the second device.

[0394] In some possible implementations, the second frame instructs the second device to interrupt the first link training and perform the second link training.

[0395] In some possible implementations, the second frame includes a preset request that triggers the second device to perform second link training.

[0396] In some possible implementations, the second frame includes first request information, which requests the second device to perform second link training based on the historical training state prior to the first link training.

[0397] In some possible implementations, the second frame includes second request information, which requests the second device to perform second link training in the current training state of the first link training.

[0398] In some possible implementations, before the first device sends a second frame to the second device in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the method further includes: the first device sending a third frame to the second device, the third frame including a training type and the training type indicating separate parameter control, or the third frame including a hold request or the training parameters included in the third frame being different from the training parameters included in the first frame.

[0399] This application embodiment also provides another chip, which includes an interface circuit and a control circuit. The interface circuit is used to transmit and receive data, and the control circuit is used to process the data so that the second device with the chip installed can implement the following link training method, namely the link training method shown in FIG20: when the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training.

[0400] In some possible implementations, when the state machine of the second device is in a new request state, in response to the following condition being met, the state machine of the second device jumps from the new request state to another new initial condition state: the second frame includes a second training type, which indicates non-individual parameter control.

[0401] In some possible implementations, when the state machine of the second device is in a new initial condition state, in response to the following condition being met, the state machine of the second device jumps from the new initial condition state to another new initial condition state: the second frame includes a second training type, the second training type indicates non-individual parameter control and indicates a second preset mode, the second preset mode is different from the first preset mode indicated by the first training type included in the first frame, the first frame is a frame received by the second device from the first device, the first frame instructs the second device to perform the first link training.

[0402] In some possible implementations, when the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: when the state machine of the second device is in a new initial condition state, in response to receiving a third frame from the first device, the state machine of the second device jumps from the new initial condition state to a new index state, wherein the third frame includes a training type and the training type indicates individual parameter control; when the state machine of the second device is in a new index state, in response to receiving a second frame, the second device performs second link training.

[0403] In some possible implementations, when the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: when the state machine of the second device is in a new request state, in response to receiving a third frame from the first device, the state machine of the second device transitions from the new request state to a waiting state, wherein the third frame includes a hold request or the training parameters included in the third frame are different from the training parameters included in the first frame; when the state machine of the second device is in a waiting state, in response to receiving the second frame, the second device performs second link training.

[0404] This application also provides a link training system, which includes a first device and a second device. The first device is used to execute the link training method shown in FIG13, and the second device is used to execute the link training method shown in FIG20.

[0405] This application also provides a communication device, which includes at least one component for executing the link training method provided in this application. For example, the component is used to execute the link training method shown in at least one of the figures in FIG13 or FIG20. Alternatively, the component possesses the functionality of at least one of the first or second components provided in this application.

[0406] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to this application are generated, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk).

[0407] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or order of execution. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another.

[0408] It should also be understood that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0409] In this application, the term "at least one" means one or more, and the term "multiple" means two or more; for example, multiple devices means two or more devices. The terms "system" and "network" are often used interchangeably herein.

[0410] It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing the particular examples only and is not intended to be limiting. As used in the description of the various examples and in the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0411] It should also be understood that the term "and / or" as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. The term "and / or" describes an association between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects are in an "or" relationship.

[0412] It should also be understood that the terms “if” and “if” can be interpreted as meaning “when” or “upon”, or “in response to determination” or “in response to detection”. Similarly, depending on the context, the phrases “if determination…” or “if detection [the stated condition or event]” can be interpreted as meaning “when determination…”, or “in response to determination…”, or “when detection [the stated condition or event]” or “in response to detection [the stated condition or event]”.

[0413] The above are merely embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for link training, characterized in that, The method includes: The first device sends a first frame to the second device, and the first frame instructs the second device to perform first link training. In response to the first device not recognizing the response of the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, the second frame instructing the second device to perform second link training.

2. The method according to claim 1, characterized in that, The first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, where the first duration is less than the timeout duration of the maximum waiting timer for link training.

3. The method according to claim 1 or 2, characterized in that, The first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, where the first duration is less than the timeout duration of the silent state.

4. The method according to any one of claims 1-3, characterized in that, The first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, where the first duration is less than the timeout duration of the recovery state.

5. The method according to any one of claims 1-4, characterized in that, The first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within 20 milliseconds after sending the first frame.

6. The method according to any one of claims 1-5, characterized in that, The first device is not locked in frames, including: the first device is not locked in frames within 20 milliseconds after sending the first frame.

7. The method according to any one of claims 1-6, characterized in that, The response to the first device not recognizing the second device, or the response to the first device not locking a frame, the first device sending a second frame to the second device includes: In response to the first device not recognizing the response of the second device, or in response to the first device not locking a frame and not entering the initialization state or silent state of the state machine of the first device, the first device directly sends the second frame to the second device.

8. The method according to any one of claims 1-7, characterized in that, The second frame instructs the second device to interrupt the first link training and execute the second link training.

9. The method according to any one of claims 1-8, characterized in that, The second frame includes a preset request, which is used to trigger the second device to perform the second link training.

10. The method according to any one of claims 1-8, characterized in that, The second frame includes first request information, which requests the second device to perform the second link training based on the historical training state prior to the first link training.

11. The method according to any one of claims 1-8, characterized in that, The second frame includes a second request information, which requests the second device to perform the second link training in the current training state of the first link training.

12. The method according to any one of claims 1-11, characterized in that, Before the first device sends a second frame to the second device in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the method further includes: The first device sends a third frame to the second device, the third frame including a training type and the training type indicating individual parameter control, or the third frame including a hold request or the training parameters included in the third frame being different from the training parameters included in the first frame.

13. A method for link training, characterized in that, The method includes: When the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training.

14. The method according to claim 13, characterized in that, When the state machine of the second device is in the new request state, in response to the following condition being met, the state machine of the second device transitions from the new request state to another new initial condition state: The second frame includes a second training type, which indicates non-individual parameter control.

15. The method according to claim 13, characterized in that, When the state machine of the second device is in the new initial condition state, the state machine of the second device transitions from the new initial condition state to another new initial condition state in response to the following condition being met: The second frame includes a second training type, which indicates non-individual parameter control and indicates a second preset mode. The second preset mode is different from the first preset mode indicated by the first training type included in the first frame. The first frame is a frame received by the second device from the first device, which indicates that the second device performs first link training.

16. The method according to claim 13, characterized in that, When the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: When the state machine of the second device is in the new initial condition state, in response to receiving a third frame from the first device, the state machine of the second device jumps from the new initial condition state to a new index state, wherein the third frame includes a training type and the training type indicates individual parameter control; When the state machine of the second device is in the new index state, in response to receiving the second frame, the second device performs second link training.

17. The method according to claim 13, characterized in that, When the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: When the state machine of the second device is in the new request state, in response to receiving a third frame from the first device, the state machine of the second device transitions from the new request state to the waiting state, wherein the third frame includes a hold request or the training parameters included in the third frame are different from the training parameters included in the first frame. When the state machine of the second device is in the waiting state, in response to receiving the second frame, the second device performs second link training.

18. A link training system, characterized in that, The system includes a first device and a second device, wherein the first device is used to perform the link training method according to any one of claims 1-12, and the second device is used to perform the link training method according to any one of claims 13-17.

19. A communication device, characterized in that, The communication device includes a transceiver and a processor. The transceiver is used to perform transmission and reception functions, and the processor is used to perform other functions besides transmission and reception functions, so that the communication device can implement the link training method according to any one of claims 1-17.

20. A chip, characterized in that, The chip includes an interface circuit and a control circuit. The interface circuit is used to transmit and receive data, and the control circuit is used to process the data so that the first device equipped with the chip can implement the following link training method: The first device sends a first frame to the second device, and the first frame instructs the second device to perform first link training. In response to the first device not recognizing the response of the second device, or in response to the first device not locking a frame, the first device sends a second frame to the second device, the second frame instructing the second device to perform second link training.

21. The chip according to claim 20, characterized in that, The first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, where the first duration is less than the timeout duration of the maximum waiting timer for link training.

22. The chip according to claim 20 or 21, characterized in that, The first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, where the first duration is less than the timeout duration of the silent state.

23. The chip according to any one of claims 20-22, characterized in that, The first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within a first duration after sending the first frame, where the first duration is less than the timeout duration of the recovery state.

24. The chip according to any one of claims 20-23, characterized in that, The first device does not recognize the response of the second device, including: the first device does not recognize the response of the second device within 20 milliseconds after sending the first frame.

25. The chip according to any one of claims 20-24, characterized in that, The first device is not locked in frames, including: the first device is not locked in frames within 20 milliseconds after sending the first frame.

26. The chip according to any one of claims 20-25, characterized in that, The response to the first device not recognizing the second device, or the response to the first device not locking a frame, the first device sending a second frame to the second device includes: In response to the first device not recognizing the response of the second device, or in response to the first device not locking a frame and not entering the initialization state or silent state of the state machine of the first device, the first device directly sends the second frame to the second device.

27. The chip according to any one of claims 20-26, characterized in that, The second frame instructs the second device to interrupt the first link training and execute the second link training.

28. The chip according to any one of claims 20-27, characterized in that, The second frame includes a preset request, which is used to trigger the second device to perform the second link training.

29. The chip according to any one of claims 20-27, characterized in that, The second frame includes first request information, which requests the second device to perform the second link training based on the historical training state prior to the first link training.

30. The chip according to any one of claims 20-27, characterized in that, The second frame includes a second request information, which requests the second device to perform the second link training in the current training state of the first link training.

31. The chip according to any one of claims 20-30, characterized in that, Before the first device sends a second frame to the second device in response to the first device not recognizing the second device, or in response to the first device not locking a frame, the method further includes: The first device sends a third frame to the second device, the third frame including a training type and the training type indicating individual parameter control, or the third frame including a hold request or the training parameters included in the third frame being different from the training parameters included in the first frame.

32. A chip, characterized in that, The chip includes an interface circuit and a control circuit. The interface circuit is used for transmitting and receiving data, and the control circuit is used for processing the data to enable the second device equipped with the chip to implement the following link training method: When the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training.

33. The chip according to claim 32, characterized in that, When the state machine of the second device is in the new request state, in response to the following condition being met, the state machine of the second device transitions from the new request state to another new initial condition state: The second frame includes a second training type, which indicates non-individual parameter control.

34. The chip according to claim 32, characterized in that, When the state machine of the second device is in the new initial condition state, the state machine of the second device transitions from the new initial condition state to another new initial condition state in response to the following condition being met: The second frame includes a second training type, which indicates non-individual parameter control and indicates a second preset mode. The second preset mode is different from the first preset mode indicated by the first training type included in the first frame. The first frame is a frame received by the second device from the first device, which indicates that the second device performs first link training.

35. The chip according to claim 32, characterized in that, When the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: When the state machine of the second device is in the new initial condition state, in response to receiving a third frame from the first device, the state machine of the second device jumps from the new initial condition state to a new index state, wherein the third frame includes a training type and the training type indicates individual parameter control; When the state machine of the second device is in the new index state, in response to receiving the second frame, the second device performs second link training.

36. The chip according to claim 32, characterized in that, When the state machine of the second device is in a new initial condition state or a new request state, in response to receiving a second frame from the first device, the second device performs second link training, including: When the state machine of the second device is in the new request state, in response to receiving a third frame from the first device, the state machine of the second device transitions from the new request state to the waiting state, wherein the third frame includes a hold request or the training parameters included in the third frame are different from the training parameters included in the first frame. When the state machine of the second device is in the waiting state, in response to receiving the second frame, the second device performs second link training.

Citation Information

Patent Citations

  • PMD sublayer link training method and system

    CN111431824A

  • Parameter determination method, integrated circuit and network equipment

    CN114513407A

  • Chip port link training connection method and application

    CN114745450A

  • Communication link initialization method and device

    CN116760502A

  • Video playing system and method

    CN117749969A