Parameter negotiation method of high-speed serial interface

Abstract

The invention provides a parameter negotiation method for a high-speed serial interface, which is applied to an adaptation layer of any chip in a chip pair for data interaction based on UCIE, and comprises the following steps: requesting a home terminal physical layer to enter an active state under the condition that the home terminal physical layer completes link training; under the condition that a home terminal physical layer enters an active state and a backdoor selection bit is not set, determining a home terminal performance index based on a link training result and home terminal performance parameters pre-configured by a user; determining a target protocol stack to be subjected to parameter negotiation and a to-be-negotiated protocol type of the target protocol stack based on the home terminal performance index, and performing parameter negotiation handshake with the opposite terminal based on the to-be-negotiated protocol type of the target protocol stack; under the condition that the parameter negotiation is successful, the target protocol and the target data format are determined based on the result of the parameter negotiation handshake, and the indication information of the target protocol and the target data format is sent to a home terminal protocol layer, so that the parameter negotiation efficiency of the high-speed serial interface can be improved.

Description

Technical Field

[0001] The present application relates to the field of high-speed interconnect technology, and in particular to a parameter negotiation method for a high-speed serial interface. Background Art

[0002] UCIE (Universal Chiplet Interconnect Express) is the fastest solution in the field of high-speed interconnection. UCIE supports multiple protocols and formats. Since the chips (i.e., dies) on both sides of UCIE may come from different manufacturers or belong to different versions, the performance of the chips on both sides may be different. In addition, affected by the physical link environment, the performance supported by the chips on both sides of UCIE may also be different at different times. However, the chips on both sides must use the same protocol and format for data transmission, so parameter negotiation is required before use.

[0003] However, the existing method of completing parameter negotiation through sideband takes a lot of time (the sideband rate is much lower than the main band for data transmission). When the physical link environment is good and the performance of the dies on both sides is exactly the same, performing parameter negotiation every time will seriously reduce the data transmission efficiency of the high-speed interface. In addition, in order to simplify control, the sideband function is usually ensured to be easy to implement by delaying the action when performing parameter negotiation, but the effective bandwidth is seriously wasted during this period. Summary of the invention

[0004] The present application provides a parameter negotiation method for a high-speed serial interface, which is used to maximize the parameter negotiation efficiency of the high-speed serial interface, thereby improving the data transmission efficiency of the high-speed serial interface.

[0005] The present application provides a parameter negotiation method for a high-speed serial interface, the method being applied to an adaptation layer of any chip in a chip pair for data interaction based on UCIE, the method comprising:

[0006] When the local physical layer completes link training, request the local physical layer to enter the active state;

[0007] When the local physical layer enters the active state and the backdoor selection bit is not set, the local performance index is determined based on the link training result and the local performance parameters pre-configured by the user;

[0008] Determine the target protocol stack to be negotiated and the protocol type to be negotiated of the target protocol stack based on the performance indicator of the local end, and perform parameter negotiation handshake with the other end based on the protocol type to be negotiated of the target protocol stack;

[0009] In the case where the parameter negotiation is successful, the target protocol and the target data format are determined based on the result of the parameter negotiation handshake, and indication information of the target protocol and the target data format is sent to the local protocol layer.

[0010] According to a parameter negotiation method for a high-speed serial interface provided by the present application, when there is only one target protocol stack, the parameter negotiation handshake is performed with the other end based on the protocol type to be negotiated of the target protocol stack, specifically including:

[0011] Step S1, determining a port mode corresponding to the target protocol stack based on the protocol type to be negotiated of the target protocol stack, and determining a single handshake mechanism corresponding to the target protocol stack based on the port mode corresponding to the target protocol stack;

[0012] Step S3, performing the first parameter negotiation handshake with the peer end based on the single handshake mechanism corresponding to the target protocol stack, and determining whether to perform the second parameter negotiation handshake based on the result of the first parameter negotiation handshake, if yes, executing step S5, otherwise, jumping to executing step S7;

[0013] Step S5, performing a secondary parameter negotiation handshake with the other end based on the single handshake mechanism corresponding to the target protocol stack;

[0014] Step S7: if the parameter negotiation fails, reporting parameter negotiation failure prompt information to the user.

[0015] According to a parameter negotiation method for a high-speed serial interface provided by the present application, when there are two target protocol stacks, the parameter negotiation handshake is performed with the other end based on the protocol type to be negotiated of the target protocol stack, specifically including:

[0016] Step S2, determining the parameter negotiation order of the target protocol stack and determining the port mode corresponding to the target protocol stack based on the protocol type to be negotiated of the target protocol stack, and determining the single handshake mechanism corresponding to the target protocol stack based on the port mode corresponding to the target protocol stack;

[0017] Step S4, based on the single handshake mechanism corresponding to the first protocol stack in the target protocol stack, perform the first parameter negotiation handshake of the first protocol stack with the peer end, and determine whether to perform the second parameter negotiation handshake of the first protocol stack based on the result of the first parameter negotiation handshake of the first protocol stack, if so, execute step S6, otherwise, jump to execute step S12;

[0018] Step S6, performing a second parameter negotiation handshake of the first protocol stack with the peer end based on the single handshake mechanism corresponding to the first protocol stack, and performing a first parameter negotiation handshake of the second protocol stack with the peer end based on the single handshake mechanism corresponding to the second protocol stack in the target protocol stack;

[0019] Step S8, based on the result of the first parameter negotiation handshake of the second protocol stack, determine whether to perform the second parameter negotiation handshake of the second protocol stack; if so, execute step S10; otherwise, jump to execute step S12;

[0020] Step S10, performing a second protocol stack secondary parameter negotiation handshake with the peer end based on the single handshake mechanism corresponding to the second protocol stack;

[0021] Step S12: When parameter negotiation fails, a prompt message indicating parameter negotiation failure is reported to the user.

[0022] According to a parameter negotiation method for a high-speed serial interface provided by the present application, determining a port mode corresponding to a target protocol stack based on a protocol type to be negotiated of the target protocol stack specifically includes:

[0023] When the protocol type to be negotiated of the target protocol stack is PCIe or CXL protocol, the port mode corresponding to the target protocol stack is DP / UP mode;

[0024] When the protocol type to be negotiated of the target protocol stack is a stream protocol, the port mode corresponding to the target protocol stack is a non-DP / UP mode.

[0025] According to a parameter negotiation method for a high-speed serial interface provided by the present application, the single handshake mechanism corresponding to the target protocol stack is determined based on the port mode corresponding to the target protocol stack, specifically including:

[0026] In the case where the port mode corresponding to the target protocol stack is the DP / UP mode, the single handshake mechanism corresponding to the target protocol stack is the first handshake mechanism; the first handshake mechanism includes three interaction processes, the first interaction process is: the downstream port adaptation layer sends a performance notification packet to the upstream port adaptation layer; the second interaction process is: the upstream port adaptation layer immediately replies to the downstream port adaptation layer with its own performance notification packet after receiving the performance notification packet from the downstream port adaptation layer; the third interaction process is: the downstream port adaptation layer immediately replies to the upstream port adaptation layer with an agreed performance notification packet after receiving the performance notification packet from the upstream port adaptation layer;

[0027] When the port mode corresponding to the target protocol stack is non-DP / UP mode, the single handshake mechanism corresponding to the target protocol stack is the second handshake mechanism; the second handshake mechanism includes two interaction processes, the first interaction process is: the adaptation layer of the local end sends a performance notification packet to the adaptation layer of the opposite end; the second interaction process is: the adaptation layer of the opposite end sends a performance notification packet to the adaptation layer of the local end.

[0028] According to a parameter negotiation method for a high-speed serial interface provided by the present application, the performance notification packet includes a function indication code, and the function indication code includes multiple function indication bits; for a target function with only one function indication bit, when the value of the function indication bit is 1, it indicates that the target function is enabled, otherwise, it indicates that the target function is disabled.

[0029] According to a parameter negotiation method for a high-speed serial interface provided by the present application, when the parameter negotiation is successful, determining the target protocol and the target data format based on the result of the parameter negotiation handshake specifically includes:

[0030] If the number of parameter negotiation handshakes corresponding to the target protocol stack is two, the target protocol and the target data format are determined based on the results of the first parameter negotiation handshake and the second parameter negotiation handshake;

[0031] If the number of parameter negotiation handshakes corresponding to the target protocol stack is one, the target protocol and the target data format are determined based on the result of the first parameter negotiation handshake.

[0032] According to a parameter negotiation method for a high-speed serial interface provided by the present application, the target protocol and the target data format are determined based on the results of the first parameter negotiation handshake and the second parameter negotiation handshake, specifically including:

[0033] Determine the target protocol based on the first target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake and the second target function indicator bit in the performance notification packet in the third interaction process corresponding to the second parameter negotiation handshake;

[0034] The target data format is determined based on the third target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake and the fourth target function indicator bit in the performance notification packet in the third interaction process corresponding to the second parameter negotiation handshake, or the target data format is determined only based on the third target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake.

[0035] According to a parameter negotiation method for a high-speed serial interface provided by the present application, determining a target protocol and a target data format based on a result of a first parameter negotiation handshake specifically includes:

[0036] In the case where the port mode corresponding to the target protocol stack is non-DP / UP mode, determining the target protocol and the target data format based on the fifth target function indicator bit in the performance notification packet in the second interaction process corresponding to the first parameter negotiation handshake;

[0037] When the port mode corresponding to the target protocol stack is the DP / UP mode, the target protocol and the target data format are determined based on the sixth target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake.

[0038] According to a parameter negotiation method of a high-speed serial interface provided by the present application, the method further includes:

[0039] When the backdoor selection bit is set, the target protocol and target data format are determined directly based on the local performance parameters pre-configured by the user.

[0040] The parameter negotiation method of the high-speed serial interface provided in the present application is applied to the adaptation layer of any chip in a chip pair for data interaction based on UCIE, and the method includes: when the local physical layer completes link training, requesting the local physical layer to enter an active state; when the local physical layer enters the active state and the backdoor selection bit is not set, determining the local performance index based on the result of the link training and the local performance parameters pre-configured by the user; determining the target protocol stack to be negotiated and the protocol type to be negotiated of the target protocol stack based on the local performance index, and performing parameter negotiation handshake with the opposite end based on the protocol type to be negotiated of the target protocol stack; when the parameter negotiation is successful, determining the target protocol and the target data format based on the result of the parameter negotiation handshake, and sending the indication information of the target protocol and the target data format to the local protocol layer, which can maximize the parameter negotiation efficiency of the high-speed serial interface, thereby improving the data transmission efficiency of the high-speed serial interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the present application or the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0042] Figure 1 It is a flow chart of a parameter negotiation method for a high-speed serial interface provided by the present application;

[0043] Figure 2 is a schematic diagram of the interaction process of the first handshake mechanism provided by this application;

[0044] Figure 3 It is a schematic diagram of the interactive process of two parameter negotiations provided by this application;

[0045] Figure 4 It is a schematic diagram of the interaction process of parameter negotiation when both protocol stacks provided by this application are PCIe protocols;

[0046] Figure 5 It is a schematic diagram of the interactive process of parameter negotiation when the first protocol stack provided by the present application is the PCIe protocol and the second protocol stack is the streaming protocol;

[0047] Figure 6 It is a schematic diagram of the interactive process of parameter negotiation when the first protocol stack provided by the present application is a stream protocol and the second protocol stack is a PCIe protocol;

[0048] Figure 7 It is a schematic diagram of the interaction process of parameter negotiation when both protocol stacks provided by this application are streaming protocols;

[0049] Figure 8 It is a schematic diagram of the interactive process of parameter negotiation when the first protocol stack provided by the present application is a stream protocol and the second protocol stack is a CXL protocol;

[0050] Fig. 9 It is a schematic diagram of the interaction process of parameter negotiation when both protocol stacks provided by this application are CXL protocols;

[0051] Fig.10 It is a schematic diagram of the function indication coding in the performance notification packet corresponding to the first parameter negotiation handshake provided by this application;

[0052] Fig.11 It is a schematic diagram of the function indication coding in the performance notification package corresponding to the secondary parameter negotiation handshake and multi-protocol stack parameter negotiation provided by this application;

[0053] Fig.12 This is a schematic diagram of the UCIE 1.0 protocol negotiation process provided by this application;

[0054] Fig.13 This is a schematic diagram of the protocol negotiation process of UCIE1.1 provided by this application;

[0055] Fig.14 This is a schematic diagram of the data format negotiation process of UCIE1.0 provided by this application;

[0056] Fig.15 This is one of the schematic diagrams of the data format negotiation process of UCIE1.1 provided by this application;

[0057] Fig.16 This is the second schematic diagram of the data format negotiation process of UCIE1.1 provided by this application;

[0058] Fig.17 It is a schematic diagram of the negotiation and judgment process of the CXL and PCIe protocols provided by this application;

[0059] Fig.18 This is a schematic diagram of the data format negotiation and judgment process of UCIE1.0 provided by this application;

[0060] Fig.19 This is a schematic diagram of the data format negotiation and judgment process of PCIe or CXL of UCIE1.1 under specific conditions provided by this application;

[0061] Fig. 20 This is a schematic diagram of the data format negotiation and judgment process for the UCIE1.1 stream protocol and other situations provided by this application;

[0062] Fig.21 It is a schematic diagram of the summary process of the protocol negotiation results provided by this application;

[0063] Fig. 22 It is a structural schematic diagram of the electronic device provided by this application. DETAILED DESCRIPTION

[0064] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below in conjunction with the drawings in this application. Obviously, the described embodiments are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0065] Figure 1 is a flow chart of a parameter negotiation method for a high-speed serial interface provided by the present application, wherein the method is applied to an adaptation layer of any chip in a chip pair for data interaction based on UCIE, such as Figure 1 As shown, the method includes:

[0066] Step 101 : When the local physical layer completes link training, request the local physical layer to enter an active state.

[0067] Specifically, it can be understood that the chip pair includes a first chip and a second chip, and the first chip and the second chip both include a protocol layer, an adaptation layer and a physical layer. The parameter negotiation method of the high-speed serial interface provided in the present application is simultaneously applied to the adaptation layer of the first chip and the second chip. The embodiment of the present application only provides a detailed introduction to the parameter negotiation method from the perspective of one of the chips (hereinafter referred to as the current chip).

[0068] More specifically, the local physical layer, i.e., the physical layer of the current chip, needs to complete link training and enter an active state (i.e., an Active state) before performing parameter negotiation so that the adaptation layer can perform parameter negotiation through the sideband. Whether the local physical layer has completed link training can be confirmed by the corresponding training completion flag. Based on this, when the local physical layer completes link training, the adaptation layer immediately sends an active state request to the physical layer to request the local physical layer to enter an active state.

[0069] Step 102, when the local physical layer enters the active state and the backdoor selection bit is not set, determine the local performance index based on the link training result and the local performance parameters pre-configured by the user.

[0070] Specifically, it is worth noting that the embodiment of the present application sets a backdoor function for the purpose of improving the efficiency of parameter negotiation, that is, the user can skip the parameter negotiation and directly configure the first chip and the second chip to the same protocol and data format. More specifically, the embodiment of the present application indicates whether to enter the backdoor function through a pre-configured backdoor selection bit. When the backdoor selection bit is set, it indicates that the backdoor function is enabled, otherwise the backdoor function is disabled. Based on this, the method also includes:

[0071] When the backdoor selection bit is set, the target protocol and target data format are determined directly based on the local performance parameters pre-configured by the user.

[0072] Based on this approach, when the physical link environment is good and the performance of the dies on both sides (i.e., the aforementioned chip pair) is completely consistent (which the user can know in advance), the parameter negotiation process can be skipped to configure the protocol and data format to increase the effective bandwidth. It can be understood that the local performance parameters are configured through registers.

[0073] However, considering that the performance of the die on both sides is sometimes not completely consistent, it is impossible to use the backdoor function for direct configuration. In this case, the embodiment of the present application determines the protocol and data format through the parameter negotiation function. Specifically, when the local physical layer enters the active state and the backdoor selection bit is not set, the local performance index is determined based on the results of the link training and the local performance parameters pre-configured by the user. The results of the link training include link width, link data rate, etc., and the local performance index can be determined in combination with the local performance parameters pre-configured by the user.

[0074] It is worth noting that the embodiment of the present application completes the configuration of the local performance parameters by reusing existing registers, that is, the local performance parameter configuration corresponding to the backdoor function and the local performance parameter configuration corresponding to the parameter negotiation use the same registers. Based on this, a large amount of register area can be saved.

[0075] Step 103: determine the target protocol stack for parameter negotiation and the protocol type to be negotiated of the target protocol stack based on the local performance indicator, and perform parameter negotiation handshake with the other end based on the protocol type to be negotiated of the target protocol stack.

[0076] Specifically, it can be understood that the target protocol stack to be negotiated for parameters on the other end, that is, the chip on the other end, may be one or two. The number of target protocol stacks is different, and the corresponding parameter negotiation handshake process is different. At the same time, the type of protocol to be negotiated on the target protocol stack is different, and the corresponding parameter negotiation handshake mechanism is also different. Based on this, after determining the performance indicators of the local end, the embodiment of the present application further determines the target protocol stack to be negotiated for parameters and the type of protocol to be negotiated on the target protocol stack based on the performance indicators of the local end, and performs parameter negotiation handshake with the other end based on the type of protocol to be negotiated on the target protocol stack. More specifically, in the case where there is one target protocol stack, the parameter negotiation handshake with the other end based on the type of protocol to be negotiated on the target protocol stack specifically includes:

[0077] Step S1, determining a port mode corresponding to the target protocol stack based on the protocol type to be negotiated of the target protocol stack, and determining a single handshake mechanism corresponding to the target protocol stack based on the port mode corresponding to the target protocol stack;

[0078] Step S3, performing the first parameter negotiation handshake with the peer end based on the single handshake mechanism corresponding to the target protocol stack, and determining whether to perform the second parameter negotiation handshake based on the result of the first parameter negotiation handshake, if yes, executing step S5, otherwise, jumping to executing step S7;

[0079] Step S5, performing a secondary parameter negotiation handshake with the other end based on the single handshake mechanism corresponding to the target protocol stack;

[0080] Step S7: if the parameter negotiation fails, reporting parameter negotiation failure prompt information to the user.

[0081] Specifically, determining the port mode corresponding to the target protocol stack based on the protocol type to be negotiated of the target protocol stack specifically includes:

[0082] When the protocol type to be negotiated of the target protocol stack is PCIe (Peripheral Component Interconnect Express) or CXL (Compute Express Link) protocol, the port mode corresponding to the target protocol stack is DP (Downstream Port) / UP (Upstream Port) mode;

[0083] When the protocol type to be negotiated of the target protocol stack is a stream protocol, the port mode corresponding to the target protocol stack is a non-DP / UP mode.

[0084] In order to maximize the efficiency of parameter negotiation, the embodiment of the present application sets different single handshake mechanisms for different port modes. Specifically, the single handshake mechanism corresponding to the target protocol stack is determined based on the port mode corresponding to the target protocol stack, specifically including:

[0085] In the case where the port mode corresponding to the target protocol stack is the DP / UP mode, the single handshake mechanism corresponding to the target protocol stack is the first handshake mechanism; the first handshake mechanism includes three interaction processes, the first interaction process is: the downstream port adaptation layer sends a performance notification packet to the upstream port adaptation layer; the second interaction process is: the upstream port adaptation layer immediately replies to the downstream port adaptation layer with its own performance notification packet after receiving the performance notification packet from the downstream port adaptation layer; the third interaction process is: the downstream port adaptation layer immediately replies to the upstream port adaptation layer with an agreed performance notification packet after receiving the performance notification packet from the upstream port adaptation layer;

[0086] When the port mode corresponding to the target protocol stack is non-DP / UP mode, the single handshake mechanism corresponding to the target protocol stack is the second handshake mechanism; the second handshake mechanism includes two interaction processes, the first interaction process is: the adaptation layer of the local end sends a performance notification packet to the adaptation layer of the opposite end; the second interaction process is: the adaptation layer of the opposite end sends a performance notification packet to the adaptation layer of the local end.

[0087] Figure 2This is a schematic diagram of the interaction process of the first handshake mechanism provided by the present application, wherein DPAdapter Die0 is the adaptation layer of the first chip (as the downstream port), DP Physical layer Die0 is the physical layer of the first chip, CHANNEL is the transmission channel, UPAdapter Die1 is the adaptation layer of the second chip (as the upstream port), UP PhysicallayerDie1 is the physical layer of the second chip, SB MSG{AdvCap.Adapter} is the performance notification packet corresponding to the first chip or the second chip, and SB MSG{FinCap.Adapter} is the agreed performance notification packet. If you want to publish support for the PCIe or CXL protocol, the upstream port (UP) adaptation layer must wait for the first message from the downstream port (DP) adaptation layer (i.e., the performance notification packet of the DP), check the functions published by the DP, and then send a sideband message carrying the functions published by itself (i.e., the performance notification packet of the UP). In order to save time for parameter negotiation, the UP side will immediately reply to the performance notification packet determined by itself after receiving the first sideband performance notification packet of the DP. Similarly, after receiving the first sideband performance notification packet from UP, DP will immediately reply {finCap.Adapter} to inform UP that DP has learned of its decided performance notification packet.

[0088] It is worth noting that when the port mode corresponding to the target protocol stack is non-DP / UP mode (i.e., the PCIe or CXL protocol is not released, and the stream protocol is to be negotiated), there is no concept of DP and UP. Based on this, in order to maximize the parameter negotiation efficiency in the non-DP / UP mode, each party independently publishes its functions, that is, the single handshake mechanism corresponding to the target protocol stack is the second handshake mechanism; the second handshake mechanism includes two interaction processes, the first interaction process is: the local adaptation layer sends a performance notification packet to the other end adaptation layer; the second interaction process is: the other end adaptation layer sends a performance notification packet to the local adaptation layer. It is worth noting that the first interaction process and the second interaction process corresponding to the second handshake mechanism are independent of each other, that is, the local end and the other end each independently send their own performance notification packets without waiting to receive the other party's performance notification packet before sending. In addition, if the stream protocol requires, it is allowed to exchange sideband messages defined by other vendors to negotiate vendor-specific extended functions.

[0089] After determining the single handshake mechanism corresponding to the target protocol stack, the first parameter negotiation handshake can be performed with the peer end based on the single handshake mechanism corresponding to the target protocol stack. After obtaining the result of the first parameter negotiation handshake, the following situations may occur:

[0090] The first is to determine that the parameter negotiation fails based on the result of the first parameter negotiation handshake (the DP / UP mode is {finCap.Adapter}, and the non-DP / UP mode is the opposite end's {AdvCap.Adapter}), and then report the parameter negotiation failure prompt information to the user; the second is to determine that the parameter negotiation succeeds based on the result of the first parameter negotiation handshake (the DP / UP mode is {finCap.Adapter}, and the non-DP / UP mode is the opposite end's {AdvCap.Adapter}), and then determine the target protocol (i.e., the protocol agreed upon by both ends) and the target data format (i.e., the data format agreed upon by both ends) based on the result of the parameter negotiation handshake, and send the indication information of the target protocol and the target data format to the local end protocol layer; the third is to determine that a secondary parameter negotiation handshake is required based on the result of the first parameter negotiation handshake. It is worth noting that a secondary parameter negotiation handshake is only possible in the DP / UP mode, so at this time, the result of the first parameter negotiation handshake is the DP / UP mode's {finCap.Adapter}. If "68B Flit Mode" or "CXL 256BFlitMode" is set in the {FinCap.Adapter} message, the details associated with this mode must be determined through another handshake of parameter negotiation (equivalent to determining the sub-function under the large function).

[0091] Figure 3 The interactive process diagram of two parameter negotiations provided for this application is as follows: Figure 3 As shown in the figure, for the convenience of distinction, the performance notification packet in the secondary parameter negotiation handshake process is represented by SB MSG{AdvCap.CXL}, and the agreed performance notification packet is represented by SB MSG{FinCap.CXL}. It is worth noting that in order to save the time of parameter negotiation, the two parameter negotiation handshakes adopt an overlapping mechanism, that is, the first packet of the secondary parameter negotiation handshake is sent immediately after the third packet of the first parameter negotiation handshake is sent.

[0092] In the case where there are two target protocol stacks, the parameter negotiation handshake is performed with the other end based on the protocol type to be negotiated of the target protocol stack, specifically including:

[0093] Step S2, determining the parameter negotiation order of the target protocol stack and determining the port mode corresponding to the target protocol stack based on the protocol type to be negotiated of the target protocol stack, and determining the single handshake mechanism corresponding to the target protocol stack based on the port mode corresponding to the target protocol stack;

[0094] Step S4, based on the single handshake mechanism corresponding to the first protocol stack in the target protocol stack, perform the first parameter negotiation handshake of the first protocol stack with the peer end, and determine whether to perform the second parameter negotiation handshake of the first protocol stack based on the result of the first parameter negotiation handshake of the first protocol stack, if so, execute step S6, otherwise, jump to execute step S12;

[0095] Step S6, performing a second parameter negotiation handshake of the first protocol stack with the peer end based on the single handshake mechanism corresponding to the first protocol stack, and performing a first parameter negotiation handshake of the second protocol stack with the peer end based on the single handshake mechanism corresponding to the second protocol stack in the target protocol stack;

[0096] Step S8, based on the result of the first parameter negotiation handshake of the second protocol stack, determine whether to perform the second parameter negotiation handshake of the second protocol stack; if so, execute step S10; otherwise, jump to execute step S12;

[0097] Step S10, performing a second protocol stack secondary parameter negotiation handshake with the peer end based on the single handshake mechanism corresponding to the second protocol stack;

[0098] Step S12: When parameter negotiation fails, a prompt message indicating parameter negotiation failure is reported to the user.

[0099] It can be understood that, when there are two target protocol stacks, for any target protocol stack, the specific process of determining the port mode, the single handshake mechanism, and the first parameter negotiation handshake and the second parameter negotiation handshake are the same as when there is only one target protocol stack, and the only difference is that the parameter negotiation order of the two target protocol stacks needs to be determined, and the parameter negotiation is performed in sequence based on the parameter negotiation order. Among them, the first protocol stack is the protocol stack that performs parameter negotiation first, and the second protocol stack is the protocol stack that performs parameter negotiation later. Figure 4 This is a schematic diagram of the interaction process of parameter negotiation when both protocol stacks provided by this application are PCIe protocols, such as Figure 4 As shown, {AdvCap.Adapter} and {FinCap.Adapter} are used to negotiate the protocol of Stack0 (i.e., the first protocol stack). {MulfiProtAdvCap.Adapter} and {MultiProtFinCap.Adapter} are used to negotiate the protocol of Stack1 (i.e., the second protocol stack). In order to save the time of parameter negotiation, the two parameter negotiation handshakes also adopt an overlapping mechanism, that is, the first packet of the second handshake is sent immediately after the third packet of the first handshake is sent. Figure 5 This is a schematic diagram of the interactive process of parameter negotiation when the first protocol stack provided by the present application is the PCIe protocol and the second protocol stack is the stream protocol, such as Figure 5As shown in the figure, the two handshakes also use an overlapping mechanism, that is, the left packet of the second handshake is sent immediately after the third packet of the first handshake is sent. After the right side receives the third packet of the first handshake, it immediately sends the right packet of the second handshake. Figure 6 This is a schematic diagram of the interactive process of parameter negotiation when the first protocol stack provided by the present application is a stream protocol and the second protocol stack is a PCIe protocol, such as Figure 6 As shown, the two handshakes use a back-to-back mechanism, that is, during the second handshake, the left side receives the packet on the right side of the first handshake and sends the left side packet of the first handshake immediately after sending the first packet of the second handshake. Figure 7 This is a schematic diagram of the interaction process of parameter negotiation when both protocol stacks provided by this application are streaming protocols, such as Figure 7 As shown in the figure, the two handshakes also use a back-to-back mechanism, that is, during the second handshake, the left side receives the right side packet of the first handshake and sends the left side packet of the first handshake immediately after sending the left side packet of the first handshake. Similarly, the right side receives the left side packet of the first handshake and sends the right side packet of the first handshake immediately after sending the right side packet of the second handshake. Figure 8 This is a schematic diagram of the interactive process of parameter negotiation when the first protocol stack provided by the present application is a stream protocol and the second protocol stack is a CXL protocol, such as Figure 8 As shown in the figure, the first two handshakes use a back-to-back mechanism, that is, in the second handshake, the left side receives the right side packet of the first handshake and sends the left side packet of the first handshake immediately after sending the left side packet of the first handshake. It is worth noting that the {*.CXL} message of the third handshake is sent with the MsgInfo code 0001h, indicating that these messages are used for Stack1 negotiation. Fig. 9 This is a schematic diagram of the interaction process of parameter negotiation when both protocol stacks provided by this application are CXL protocols, such as Fig. 9 As shown in the figure, the second and third handshakes use a back-to-back mechanism, that is, the third handshake is performed immediately after the third packet is sent from the left side during the second handshake. It is worth noting that the {*.CXL} messages of the second handshake are sent with the MsgInfo code 0000h, indicating that these messages are used for Stack0 negotiation, and the {*.CXL} messages of the fourth handshake are sent with the MsgInfo code 0001h, indicating that these messages are used for Stack1 negotiation.

[0100] It should be noted that the performance notification package includes a function indication code, which includes multiple function indication bits; for a target function with only one function indication bit, when the value of the function indication bit is 1, it indicates that the target function is enabled, otherwise, it indicates that the target function is disabled. Fig.10 This is a schematic diagram of the function indication coding in the performance notification package corresponding to the first parameter negotiation handshake provided by this application, such as Fig.10As shown in the figure, the function indication coding (i.e., Data BitEncodings in the figure) of the performance notification packet (including {AdvCap.Adapter} and {finCap.Adapter}) corresponding to the first parameter negotiation handshake includes the following function indication bits:

[0101] 1. "Raw Format": This parameter is published if the corresponding bit in the UCIe link control register is 1b. Software / firmware decides whether to support this feature based on the system usage scenario. If PCIe or CXL protocols are not supported, and the streaming protocol is to be negotiated without any vendor-specific extensions, and other Flit Format streaming protocols are not supported, "Raw_Mode" must be 1b and published.

[0102] 2. "68B Flit Mode": Protocol parameter. If the adaptation layer and protocol layer support CXL 68B Flit Mode or PCIe Non-Flit Mode, they must be notified. If the final negotiated protocol is PCIe Non-Flit Mode, the CXL.io 68B Flit Mode format is used, which is defined in the CXL 2.0 specification.

[0103] 3. "CXL 256B Flit Mode": protocol parameter. If the adaptation layer and protocol layer support CXL 256B Flit mode, they must be advertised.

[0104] 4. "PCIe Flit Mode": Protocol parameter. If the adaptation layer and protocol layer support PCIe Flit mode, they must be notified.

[0105] 5. "Streaming": Protocol parameters. If the adaptation layer and protocol layer support the Streaming protocol in Raw mode or other FlitFormat's Streaming protocol and this function is enabled, this function must be announced.

[0106] 6. "Retry": If the adapter layer supports retry, it must notify this. If the adapter decides to support retry, but does not configure the retry feature or the retry feature negotiation fails, the link will be unavailable unless only Raw Mode is supported.

[0107] 7. "Multi_Protocol_Enable": This must be advertised only when the adaptation layer is connected to multiple FDI instances corresponding to two sets of protocol layers. This must be issued only when the adaptation layer (or the SoC firmware in the link initialization phase) determines that the UCIe link must operate in this mode. If this bit is issued, both "Stack0_Enable" and "Stack1_Enable" must be 1b.

[0108] 8. "Stack0_Enable": If the protocol layer corresponding to stack 0 exists and related operations are enabled to support the published protocol, this bit must be set.

[0109] 9. "Stack1_Enable": If the protocol layer corresponding to stack 1 exists and related operations are enabled to support the published protocol, this bit must be set.

[0110] 10. "CXL_LatOpt_Fmt5": If the adaptation layer and protocol layer support Format 5, this must be advertised. The protocol layer does not utilize the idle bytes in this Flit format. This cannot be issued when CXL's CXLprotocol and 256B Flit Mode are not supported or enabled.

[0111] 11. "CXL_LatOpt_Fmt6": If the adaptation layer and protocol layer support Format 6, this must be advertised. The protocol layer is utilizing the free bytes in this Flit format. This cannot be issued when CXL's CXLprotocol and 256B Flit Mode are not supported or enabled.

[0112] 12. "Retimer": If a UCIe Retimer's adaptation layer performs parameter negotiation with the UCIe Die in its package, it must be notified.

[0113] 13. "Retiimer_Credits": This is a 9-bit value, the total credits available in the Retimer receiver buffer. Each credit corresponds to 256B of data.

[0114] 14. "DP": Set by the downstream port to inform the remote link partner that it is a downstream port. Can be used by the retimer to identify if they are connected to a downstream port UCIe die. Currently only applies to PCIe and CXL protocols, but streaming protocols do not exclude the use of this bit. If the retimer is set to 1b, this bit must be set to 0b.

[0115] 15. "UP": Set by the upstream port to inform the remote link partner that it is an upstream port. Can be used by retimers to identify if they are connected to an upstream port UCIe die. Currently only applies to PCIe and CXL protocols, but streaming protocols do not exclude the use of this bit. If Retimer is set to 1b, this bit must be set to 0b.

[0116] 16. "68B Flit Format": This bit must be set if any of the following conditions are true: The Enhanced Multi-Protocol capability is supported and enabled, and the 68B Flit format is supported and enabled; the 68B Flit Format for Streaming Protocol function is supported and enabled, otherwise it must be set to 0b.

[0117] 17. "Standard 256B End Header Flit Format": This bit must be set if any of the following conditions are true: The Enhanced Multi-Protocol capability is supported and enabled, and the Standard 256B End Header Flit Format is supported and enabled; the Standard 256B End Header FlitFormat for Streaming Protocol function is supported and enabled, otherwise it must be set to 0b.

[0118] 18. "Standard256B StartHeaderFlitFormat": This bit must be set if any of the following conditions are true: The Enhanced Multi-Protocol capability is supported and enabled, and the Standard256B Start Header Flit Format is supported and enabled; the Standard 256B Start Header FlitFormat for Streaming Protocol function is supported and enabled, otherwise it must be set to 0b.

[0119] 19. "Latency-Optimized 256B without Optional Bytes Flit Format": This bit must be set if any of the following conditions are true: The EnhancedMulti-Protocolcapability is supported and enabled, and the Latency-Optimized 256B without Optional Bytes FlitFormat is supported and enabled; The Latency-Optimized256B without Optional Bytes Flit Formatfor Streaming Protocol function is supported and enabled, otherwise it must be set to 0b.

[0120] 20. "Latency-Optimized 256B with Optional Bytes Flit Format": This bit must be set if any of the following conditions are true: PCIe Flit Mode is published, and Latency-Optimized Flit with Optional Bytes for PCIe protocol is supported and enabled; EnhancedMulti-Protocol capability is supported and enabled, and Latency-Optimized 256B with OptionalBytes Flit Format is supported and enabled; Latency-Optimized256B with Optional Bytes FlitFormat for Streaming Protocol function is supported and enabled, otherwise it must be set to 0b.

[0121] 21. "Enhanced Multi_Protocol_Enable": Enhanced Multi_Protocol_Enable must be set only when the adaptation layer is connected to multiple FDI instances corresponding to two sets of protocol layers. The two sets of protocol layers can be different protocols, but must support at least one common Flit format. Enhanced Multi_Protocol_Enable must be set only if the enhanced multi-protocol feature is supported and enabled; otherwise it must be set to 0b. "Stack0_Enable" and "Stack1_Enable" must be 1b if Enhanced Multi_Protocol_Enable is set.

[0122] 22. "Stack 0 Maximum Bandwidth_Limit": If Enhanced Multi_Protocol_Enable is set and the Stack 0 protocol receiver is limited to 50% of the maximum bandwidth, then Stack0 Maximum Bandwidth_Limit must be set; otherwise it must be set to 0b.

[0123] 23. "Stack 1 Maximum Bandwidth_Limit": If Enhanced Multi_Protocol_Enable is set and the Stack 1 protocol receiver is limited to 50% of the maximum bandwidth, then Stack1 Maximum Bandwidth_Limit must be set; otherwise it must be set to 0b.

[0124] In order to support multiple scenarios in one negotiation, the above information can be expanded to provide the negotiation results desired by the local end in various scenarios.

[0125] Fig.11 This is a schematic diagram of the function indication coding in the performance notification package corresponding to the secondary parameter negotiation handshake and multi-protocol stack parameter negotiation provided by this application, such as Fig.11 As shown, the function indication bits included in the function indication codes (ie, DataBitEncodings in the figure) of {AdvCap.CXL}, {finCap.CXL}, {MultiProtAdvCap.Adapter} and {MultiProtFinCap.Adapter} are described in detail, and the embodiments of the present application will not be repeated here.

[0126] Based on the above content, the setting method of the function indicator bit in {FinCap.Adapter} is as follows:

[0127] If "68B FlitMode" is issued by both Link partners (i.e. first chip and second chip), then set it to 1b in {FinCap.Adapter}.

[0128] If "CXL 256B Flit Mode" is advertised by both link partners, set it to 1b in {FinCap.Adapter}.

[0129] If both sides of the link advertise "PCIe Flit Mode", then set the "PCIeFlit Mode" bit to 1b in {FinCap.Adapter}.

[0130] If "Streaming" is published by both Link partners, set "Streaming" to 1b in {FinCap.Adapter}.

[0131] If "Raw_Mode" is advertised by both link partners, set "Raw_Mode" to 1b in {FinCap.Adapter}.

[0132] If both Link Partners publish "retry" and the negotiated Format is not Raw Format, the Adaptation Layer retry is enabled and "retry" is set to 1b in {FinCap.Adapter}.

[0133] If both link partners publish "EnhancedMulti_Protocol_Enable", the Adaptation Layer enables both Stack0 and Stack1 and all three parameters ("Enhanced Multi_Protocol_Enable", "Stack0_Enable" and "Stack1_Enable") are set to 1b in {FinCap.Adapter} (if {FinCap.Adapter} needs to be sent).

[0134] If both Link partners publish "Multi_Protocol_Enable" and Enhanced Multi_Protocol_Enable is not negotiated successfully (whether the sub-stacks in the two dies of the multi-protocol are the same protocol, if so, it is multi, otherwise, enhanced), the adaptation layer enables Stack0 and Stack1 at the same time, and all three parameters ("Multi_Protocol_Enable", "Stack0_Enablee" and "Stack1_Enable") are set to 1b in {FinCap.Adapter}.

[0135] If no negotiation succeeds "Enhanced Multi_Protocol_Enable" or "Multi_Protocol_Enable", the lowest common denominator is used to determine whether to enable Stack0 or Stack1, and the corresponding bit is set to 1b in {FinCap.Adapter}. If both Stack enable are issued, Stack0 is selected as the operation mode, and only Stack0_Enable is set to 1b in {FinCap.Adapter}.

[0136] If CXL_LatOpt_Fmt5 is issued by both, set it to 1b in {FinCap.Adapter}.

[0137] If CXL_LatOpt_Fmt6 is issued by both, set it to 1b in {FinCap.Adapter}.

[0138] By analogy, the embodiments of the present application are not exhaustive here.

[0139] Step 104: If the parameter negotiation is successful, determine the target protocol and the target data format based on the result of the parameter negotiation handshake, and send indication information of the target protocol and the target data format to the local protocol layer.

[0140] Specifically, when a parameter negotiation handshake is performed with the other end based on the protocol type to be negotiated of the target protocol stack and the parameter negotiation is determined to be successful, the target protocol and the target data format can be determined based on the result of the parameter negotiation handshake. More specifically, when the parameter negotiation is successful, determining the target protocol and the target data format based on the result of the parameter negotiation handshake specifically includes:

[0141] If the number of parameter negotiation handshakes corresponding to the target protocol stack is two, the target protocol and the target data format are determined based on the results of the first parameter negotiation handshake and the second parameter negotiation handshake;

[0142] If the number of parameter negotiation handshakes corresponding to the target protocol stack is one, the target protocol and the target data format are determined based on the result of the first parameter negotiation handshake.

[0143] The determining of the target protocol and the target data format based on the results of the first parameter negotiation handshake and the second parameter negotiation handshake specifically includes:

[0144] Determine the target protocol based on the first target function indicator bit in the performance notification packet (i.e., {FinCap.Adapter} or {MultiiProtFinCap.Adapter}) in the third interaction process corresponding to the first parameter negotiation handshake and the second target function indicator bit in the performance notification packet (i.e., {FinCap.CXL}) in the third interaction process corresponding to the second parameter negotiation handshake;

[0145] The target data format is determined based on the third target function indicator bit in the performance notification package (i.e., {FinCap.Adapter}) in the third interaction process corresponding to the first parameter negotiation handshake and the fourth target function indicator bit in the performance notification package (i.e., {FinCap.CXL}) in the third interaction process corresponding to the second parameter negotiation handshake, or the target data format is determined only based on the third target function indicator bit in the performance notification package in the third interaction process corresponding to the first parameter negotiation handshake.

[0146] Fig.12 This is a schematic diagram of the UCIE1.0 protocol negotiation process provided by this application. Fig.13 This is a schematic diagram of the UCIE1.1 protocol negotiation process provided by this application. Figure 12-13 As shown, for both UCIE1.0 and UCIE1.1, the first target function indicator is 68B Flitit Mode, CXL 256B Flit Mode, PCIe Flit Mode and Streaming, and the second target function indicator is PCIe and CXL.io. It can be understood that if the Enhanced_Multi-Protocol capability (corresponding to two protocol stacks) needs to be negotiated, the protocol of Stack 1 is determined by {MultiProt*.Adapter}, and the protocol of Stack 0 is determined by {FinCap*.Adapter}.

[0147] Fig.14 This is a schematic diagram of the data format negotiation process of UCIE1.0 provided by this application, such as Fig.14 As shown, for UCIE1.0, it is necessary to determine the target data format based on the third target function indication bit (i.e., Raw_Mode, 68B Flit Mode, CXL 256BFlitMode, PCIe Flit Mode, CXL_LatOpt_Fmt5, CXL_LatOpt_Fmt6) in the performance notification package (i.e., {FinCap.Adapter}) in the third interaction process corresponding to the first parameter negotiation handshake and the fourth target function indication bit (i.e., 68B_Enhanced Flit) in the performance notification package (i.e., {FinCap.CXL}) in the third interaction process corresponding to the second parameter negotiation handshake.

[0148] For UCIE1.1, the target data format only needs to be determined based on the third target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake. Fig.15This is one of the data format negotiation process diagrams of UCIE1.1 provided in this application, which corresponds to the PCIe or CXL protocol under specific conditions, where the specific conditions refer to the following conditions not being met:

[0149] 1. Enhanced Multi_Protocol_Enable;

[0150] 2. Standard 256B Start Header for PCIe protocol capability;

[0151] 3. Latency-Optimized Flit with Optional Bytes for PCIe protocolcapability.

[0152] Fig.16 This is the second schematic diagram of the data format negotiation process of UCIE1.1 provided by this application, which corresponds to the stream protocol and other situations. Figure 15-16 It can be seen that UCIE1.1 no longer supports Format7 and there is no need to refer to {FinCap.CXL}.

[0153] Further, if the number of parameter negotiation handshakes corresponding to the target protocol stack is one, determining the target protocol and the target data format based on the result of the first parameter negotiation handshake specifically includes:

[0154] In the case where the port mode corresponding to the target protocol stack is non-DP / UP mode, determining the target protocol and the target data format based on the fifth target function indicator bit in the performance notification packet in the second interaction process corresponding to the first parameter negotiation handshake;

[0155] When the port mode corresponding to the target protocol stack is the DP / UP mode, the target protocol and the target data format are determined based on the sixth target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake.

[0156] It can be understood that the fifth target function indicator bit and the sixth target function indicator bit are function indicator bits that need to be understood to determine the protocol and data format, and the embodiments of the present application will not be described in detail here.

[0157] Fig.17 This is a schematic diagram of the negotiation and judgment process of the CXL and PCIe protocols provided by this application, such as Fig.17 As shown in the figure, when UP receives {FinCap.CXL}, the parameter negotiation secondary handshake ends. Fig.12 or Fig.13To determine the intermediate result of the protocol negotiation. The signal up_fincap_cxl_en in the flowchart indicates that UP can start to preliminarily determine the protocol type after receiving {FinCap.CXL}. fincap_68b_flit_mode indicates the sub-parameter 68B Flit Mode of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_256b_flit_mode indicates the sub-parameter CXL 256B Flit Mode of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_pcie_flit_mode indicates the sub-parameter number PCIe Flit Mode of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_io_enable indicates the sub-parameter number CXL.io capable / enable of {FinCap.CXL} received by UP at the end of the second handshake of parameter negotiation. fincap_pcie_enable indicates the sub-parameter PCIe capable / enable of {FinCap.CXL} received by UP at the end of the second handshake of parameter negotiation. fincap_cx1_io_throttle indicates the sub-parameter CXL.ioThrottle of {FinCap.CXL} received by UP at the end of the second handshake of parameter negotiation. fincap_cxl_multi_logical indicates the sub-parameter Multi-Logica1 Device of {FinCap.CXL} received by UP at the end of the second handshake of parameter negotiation. Among them, Y indicates that the relevant sub-parameter is set to 1b, and N indicates that the relevant sub-parameter is set to 0b.

[0158] Fig.18 This is a schematic diagram of the data format negotiation and judgment process of UCIE1.0 provided by this application, such as Fig.18 As shown in the figure, when UP receives {FinCap.CXL}, the parameter negotiation secondary handshake ends. Fig.14To determine the result of format negotiation. The signal up_fincap_cxl_en in the flowchart indicates that UP can start to determine the format type after receiving {FinCap.CXL}. fincap_raw_mode indicates the sub-parameter Raw_Mode of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_256b_flit_mode indicates the sub-parameter number CXL 256B Flit Mode of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_latopt_fimt6 indicates the sub-parameter CXL_LatOpt_Fmt6 of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_latopt_fmt5 indicates the sub-parameter CXL_LatOpt_Fmt5 of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_pcie_flit_mode indicates the PCIe Flit Mode sub-parameter of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_68b_flit_mode indicates the 68B Flit Mode sub-parameter of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_68b_enhanced_flit_mode indicates the CXL 68B-Enhanced Flit Mode sub-parameter of {FinCap.CXL} received by UP at the end of the second handshake of parameter negotiation. Among them, Y indicates that the relevant sub-parameter is set to 1b, and N indicates that the relevant sub-parameter is set to 0b.

[0159] Fig.19 This is a schematic diagram of the data format negotiation and judgment process of PCIe or CXL of UCIE1.1 under specific conditions provided by this application, such as Fig.19 As shown in the figure, when UP receives {FinCap.Adapter}, the parameter negotiation handshake ends. Fig.15to determine the result of format negotiation. The signal start in the flowchart indicates that UP can start to determine the format type after receiving {FinCap.Adapter}. fincap_raw_format indicates the sub-parameter Raw Format of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_256b_flit_mode indicates the sub-parameter CXL 256B Flit Mode of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_latopt_fmt6 indicates the sub-parameter CXL_LatOpt_Fmt6 of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_latopt_fmt5 indicates the sub-parameter CXL_LatOpt_Fmt5 of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_pcie_flit_mode indicates the sub-parameter PCIe Flit Mode of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_68b_flit_mode indicates the sub-parameter 68B FlitMode of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. Among them, Y indicates that the relevant sub-parameter is set to 1b, and N indicates that the relevant sub-parameter is set to 0b.

[0160] Fig. 20 This is a schematic diagram of the data format negotiation and judgment process of the UCIE1.1 stream protocol and other situations provided by this application, wherein the other situation refers to any one of the following conditions being met:

[0161] 1. Enhanced Multi_Protocol_Enable;

[0162] 2. Standard 256B Start Header for PCIe protocol capability;

[0163] 3. Latency-Optimized Flit with Optional Bytes for PCIe protocolcapability.

[0164] like Fig. 20 As shown, it can be Fig.16to determine the result of format negotiation. The signal start in the flowchart indicates that when {FinCap.Adapter} is received in DP / UP mode, the format type can be determined; when {AdvCap.Adapter} is received in non-DP UP mode, the format type can be determined. x_raw_format indicates the sub-parameter Raw Format of {*Cap.Adapter} received when starting to determine the format type. x_latency_*_with* indicates the sub-parameter Latency-Optimized 256B with Optional Bytes F1itFormat of {*Cap.Adapter} received when starting to determine the format type. x_standard_*_start* indicates the sub-parameter Standard256BStart Header Flit Format of {*Cap.Adapter} received when starting to determine the format type. x_standard_*_end* indicates the sub-parameter Standard 256B End Header Flit Format of {*Cap.Adapter} received when starting to determine the format type. x_68b_flit_format indicates the sub-parameter 68B FlitFormat of {*Cap.Adapter} received when starting to determine the format type. x_1atency_*_without indicates the sub-parameter Latency-Optimized 256B without Optional Bytes FlitFormat of {*Cap.Adapter} received when starting to determine the format type. Among them, Y indicates that the relevant sub-parameter is set to 1b, N indicates that the relevant sub-parameter is set to 0b; * indicates a wildcard; x indicates different prefixes of the two modes, for example, x_raw_format indicates: In DP / UP mode: fincap_raw_format indicates the sub-parameter Raw Format of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. In non-DP / UP mode: advcap_raw_format indicates the sub-parameter Raw Format of {AdvCap.Adapter} received by DP / UP during parameter negotiation.

[0165] After the data format is confirmed and the protocol type is initially confirmed, the final result of the protocol negotiation can be determined for publication. Fig.21 This is a schematic diagram of the summary process of the protocol negotiation results provided by this application, such as Fig.21As shown, the signal fdi_bring_up_idx indicates that the confirmation of the format type and the preliminary confirmation of the protocol type are completed in DP / UP mode or non-DP / UP mode. pcie_non_flit_mode indicates that the preliminary confirmation result of the protocol type is PCIE Non Flit Mode. standard_256b_flit_mode_for_pcie indicates that the preliminary confirmation result of the protocol type is Standard 256B Flit ModeforPCIE.

[0166] only_raw_mode_flag indicates: in DP / UP mode, the 68BFlitMode sub-parameter received by DP is 0b, the CXL 256B Flit Mode sub-parameter is 0b, and the Streaming sub-parameter is 0b, and the 68B Flit Mode sub-parameter received by UP is 0b, the CXL 256B Flit Mode sub-parameter is 0b, and the Streaming sub-parameter is 0b; in non-DP / UP mode, the 68B Flit Mode sub-parameter received by DP / UP is 0b, the CXL 256B Flit Mode sub-parameter is 0b, and the Streaming sub-parameter is 0b. advcap_raw_mode indicates: in DP / UP mode, the Raw_Mode sub-parameter received by DP is 1b, and the Raw_Mode sub-parameter received by UP is 1b; in non-DP / UP mode, the Raw_Mode sub-parameter received by DP / UP is 1b.

[0167] only_streaming_mode_flag indicates: in DP / UP mode, the sub-parameter 68BFlit Mode of {AdvCap.Adapter} received by DP is 0b and the sub-parameter CXL 256B Flit Mode is 0b, and the sub-parameter 68B Flit Mode of {FinCap.Adapter} received by UP is 0b and the sub-parameter CXL 256B Flit Mode is 0b; in non-DP / UP mode, the sub-parameter 68B Flit Mode of {AdvCap.Adapter} received by DP / UP is 0b and the sub-parameter CXL 256B Flit Mode is 0b.

[0168] advcap_streaming_mode indicates: in DP / UP mode, the sub-parameter Raw_Mode of {AdvCap.Adapter} received by DP is 0b, and the sub-parameter Raw_Mode of {FinCap.Adapter} received by UP is 0b; in non-DP / UP mode, the Raw_Mode of {AdvCap.Adapter} received by DP / UP is 0b.

[0169] fincap_cxl_version_2_0_enable indicates the number of sub-parameters CXL 2.0 capable of {FinCap.CXL} received by UP at the end of the second handshake of parameter negotiation. fincap_multi_protocol enable indicates the number of sub-parameters Multi_Protocol_Enable of {FinCap.Adapter} received by UP at the end of the first handshake of parameter negotiation. fincap_cxl_mem_enable indicates the number of sub-parameters CXL.mem capable / enable of {FinCap.CXL} received by UP at the end of the second handshake of parameter negotiation. fincap_cxl_cache enable indicates the number of sub-parameters CXL.cachecapable / enable of {FinCap.CXL} received by UP at the end of the second handshake of parameter negotiation. Among them, Y indicates that the relevant sub-parameter is set to 1b, and N indicates that the relevant sub-parameter is set to 0b.

[0170] The embodiment of the present application also sets a timeout mechanism for parameter negotiation, that is, the adaptation layer must complete the parameter exchange within 8ms. Once overflowed, the Adapter needs to put the DPHY into the LinkError state. If the adaptation layer receives the {AdvCap.*.Stall}or{FinCap.*.Stall} message from the other end, the timer must be reset. Among them, the timer is incremented only when the RDI is in the Active state. The embodiment of the present application also sets a Retimer Package mechanism for parameter negotiation, that is, the UCIeRetimer must ensure that before responding / starting the parameter exchange with the UCIe die in its package, they have completed the function release and merged their own functions with the remote Retimer partner. During the parsing process, they must send a corresponding stall message (reset timing) every 4 milliseconds to ensure that the UCIe die in its package has not timed out.

[0171] The method provided in the embodiment of the present application is applied to a chip pair for data interaction based on UCIE, wherein the adaptation layer of the first chip in the chip pair includes a data sending module, and the adaptation layer of the second chip in the chip pair includes a data receiving module, and the method includes: the data sending module sends a target retransmission data batch to the data receiving module based on a target data retransmission request; the target retransmission data batch is located in a retransmission buffer of the adaptation layer of the first chip, and the retransmission buffer includes a plurality of sub-buffers with consecutive numbers, each of which has the same depth and is used to sequentially cache consecutive data batches from the protocol layer; the data receiving module detects whether there is a duplicate data packet based on the data number and the confirmed data number of the data packet in the target retransmission data batch, and immediately returns a duplicate data packet confirmation character to the data sending module if a duplicate data packet is detected; after receiving the duplicate data packet confirmation character, the data sending module stops sending the target retransmission data batch and sends a new data batch from the protocol layer to the data receiving module, thereby realizing efficient and accurate determination and processing of duplicate data packets in a high-speed serial interface.

[0172] Fig. 22 An example of a physical structure diagram of an electronic device is shown in FIG. Fig. 22 As shown, the electronic device may include: a processor 201, a communication interface 202, a memory 203 and a communication bus 204, wherein the processor 201, the communication interface 202 and the memory 203 complete mutual communication through the communication bus 204. The processor 201 may call the logic instructions in the memory 203 to execute the parameter negotiation method of the high-speed serial interface provided by the above methods, the method comprising: requesting the local physical layer to enter the active state when the local physical layer completes the link training; determining the local performance index based on the link training result and the local performance parameter pre-configured by the user when the local physical layer enters the active state and the backdoor selection bit is not set; determining the target protocol stack to be negotiated and the protocol type to be negotiated of the target protocol stack based on the local performance index, and performing parameter negotiation handshake with the opposite end based on the protocol type to be negotiated of the target protocol stack; determining the target protocol and the target data format based on the result of the parameter negotiation handshake when the parameter negotiation is successful, and sending the indication information of the target protocol and the target data format to the local protocol layer.

[0173] In addition, the logic instructions in the above-mentioned memory 203 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on such an understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art, and the computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a magnetic disk or an optical disk.

[0174] Of course, the above logic instructions can also be implemented in the form of hardware functional units. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a hardware product, and the hardware product can be used as a hardware functional module of a chip to execute all or part of the steps of the method described in each embodiment of the present application, so as to realize efficient parameter negotiation of a high-speed serial interface.

[0175] On the other hand, the present application also provides a computer program product, which includes a computer program, which can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the parameter negotiation method of the high-speed serial interface provided by the above methods, the method including: when the local physical layer completes link training, requesting the local physical layer to enter an active state; when the local physical layer enters the active state and the backdoor selection bit is not set, determining the local performance indicator based on the result of the link training and the local performance parameters pre-configured by the user; determining the target protocol stack to be negotiated and the protocol type to be negotiated of the target protocol stack based on the local performance indicator, and performing a parameter negotiation handshake with the other end based on the protocol type to be negotiated of the target protocol stack; when the parameter negotiation is successful, determining the target protocol and target data format based on the result of the parameter negotiation handshake, and sending the indication information of the target protocol and target data format to the local protocol layer.

[0176] On the other hand, the present application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the parameter negotiation method of the high-speed serial interface provided by the above-mentioned methods, the method comprising: when the local physical layer completes link training, requesting the local physical layer to enter an active state; when the local physical layer enters the active state and the backdoor selection bit is not set, determining the local performance index based on the result of the link training and the local performance parameters pre-configured by the user; determining the target protocol stack to be negotiated and the type of protocol to be negotiated of the target protocol stack based on the local performance index, and performing a parameter negotiation handshake with the other end based on the type of protocol to be negotiated of the target protocol stack; when the parameter negotiation is successful, determining the target protocol and target data format based on the result of the parameter negotiation handshake, and sending the indication information of the target protocol and target data format to the local protocol layer.

[0177] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0178] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as a ROM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0179] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A parameter negotiation method for a high-speed serial interface, characterized in that: The method is applied to the adaptation layer of any chip in a chip pair for data interaction based on UCIE, and the method includes: When the local physical layer completes link training, request the local physical layer to enter the active state; When the local physical layer enters the active state and the backdoor selection bit is not set, the local performance index is determined based on the link training result and the local performance parameters pre-configured by the user; Determine the target protocol stack to be negotiated and the protocol type to be negotiated of the target protocol stack based on the performance indicator of the local end, and perform parameter negotiation handshake with the other end based on the protocol type to be negotiated of the target protocol stack; In the case where the parameter negotiation is successful, the target protocol and the target data format are determined based on the result of the parameter negotiation handshake, and indication information of the target protocol and the target data format is sent to the local protocol layer.

2. The parameter negotiation method of the high-speed serial interface according to claim 1, characterized in that: In the case where there is only one target protocol stack, the parameter negotiation handshake is performed with the other end based on the protocol type to be negotiated of the target protocol stack, specifically including: Step S1, determining a port mode corresponding to the target protocol stack based on the protocol type to be negotiated of the target protocol stack, and determining a single handshake mechanism corresponding to the target protocol stack based on the port mode corresponding to the target protocol stack; Step S3, performing the first parameter negotiation handshake with the peer end based on the single handshake mechanism corresponding to the target protocol stack, and determining whether to perform the second parameter negotiation handshake based on the result of the first parameter negotiation handshake, if yes, executing step S5, otherwise, jumping to executing step S7; Step S5, performing a secondary parameter negotiation handshake with the other end based on the single handshake mechanism corresponding to the target protocol stack; Step S7: if the parameter negotiation fails, reporting parameter negotiation failure prompt information to the user.

3. The parameter negotiation method of the high-speed serial interface according to claim 2, characterized in that: In the case where there are two target protocol stacks, the parameter negotiation handshake is performed with the other end based on the protocol type to be negotiated of the target protocol stack, specifically including: Step S2, determining the parameter negotiation order of the target protocol stack and determining the port mode corresponding to the target protocol stack based on the protocol type to be negotiated of the target protocol stack, and determining the single handshake mechanism corresponding to the target protocol stack based on the port mode corresponding to the target protocol stack; Step S4, based on the single handshake mechanism corresponding to the first protocol stack in the target protocol stack, perform the first parameter negotiation handshake of the first protocol stack with the peer end, and determine whether to perform the second parameter negotiation handshake of the first protocol stack based on the result of the first parameter negotiation handshake of the first protocol stack, if so, execute step S6, otherwise, jump to execute step S12; Step S6, performing a second parameter negotiation handshake of the first protocol stack with the peer end based on the single handshake mechanism corresponding to the first protocol stack, and performing a first parameter negotiation handshake of the second protocol stack with the peer end based on the single handshake mechanism corresponding to the second protocol stack in the target protocol stack; Step S8, based on the result of the first parameter negotiation handshake of the second protocol stack, determine whether to perform the second parameter negotiation handshake of the second protocol stack; if so, execute step S10; otherwise, jump to execute step S12; Step S10, performing a second protocol stack secondary parameter negotiation handshake with the peer end based on the single handshake mechanism corresponding to the second protocol stack; Step S12: When parameter negotiation fails, a prompt message indicating parameter negotiation failure is reported to the user.

4. The parameter negotiation method of the high-speed serial interface according to claim 2 or 3, characterized in that: The determining of the port mode corresponding to the target protocol stack based on the protocol type to be negotiated of the target protocol stack specifically includes: When the protocol type to be negotiated of the target protocol stack is PCIe or CXL protocol, the port mode corresponding to the target protocol stack is DP / UP mode; When the protocol type to be negotiated of the target protocol stack is a stream protocol, the port mode corresponding to the target protocol stack is a non-DP / UP mode.

5. The parameter negotiation method of the high-speed serial interface according to claim 4, characterized in that: The determining of the single handshake mechanism corresponding to the target protocol stack based on the port mode corresponding to the target protocol stack specifically includes: In the case where the port mode corresponding to the target protocol stack is the DP / UP mode, the single handshake mechanism corresponding to the target protocol stack is the first handshake mechanism; the first handshake mechanism includes three interaction processes, the first interaction process is: the downstream port adaptation layer sends a performance notification packet to the upstream port adaptation layer; the second interaction process is: the upstream port adaptation layer immediately replies to the downstream port adaptation layer with its own performance notification packet after receiving the performance notification packet from the downstream port adaptation layer; the third interaction process is: the downstream port adaptation layer immediately replies to the upstream port adaptation layer with an agreed performance notification packet after receiving the performance notification packet from the upstream port adaptation layer; When the port mode corresponding to the target protocol stack is non-DP / UP mode, the single handshake mechanism corresponding to the target protocol stack is the second handshake mechanism; the second handshake mechanism includes two interaction processes, the first interaction process is: the adaptation layer of the local end sends a performance notification packet to the adaptation layer of the opposite end; the second interaction process is: the adaptation layer of the opposite end sends a performance notification packet to the adaptation layer of the local end.

6. The parameter negotiation method of the high-speed serial interface according to claim 5, characterized in that: The performance notification package includes a function indication code, which includes multiple function indication bits; for a target function with only one function indication bit, when the value of the function indication bit is 1, it indicates that the target function is enabled, otherwise, it indicates that the target function is disabled.

7. The parameter negotiation method of the high-speed serial interface according to claim 6, characterized in that: In the case where the parameter negotiation is successful, determining the target protocol and the target data format based on the result of the parameter negotiation handshake specifically includes: If the number of parameter negotiation handshakes corresponding to the target protocol stack is two, the target protocol and the target data format are determined based on the results of the first parameter negotiation handshake and the second parameter negotiation handshake; If the number of parameter negotiation handshakes corresponding to the target protocol stack is one, the target protocol and the target data format are determined based on the result of the first parameter negotiation handshake.

8. The parameter negotiation method of the high-speed serial interface according to claim 7, characterized in that: The determining of the target protocol and the target data format based on the results of the first parameter negotiation handshake and the second parameter negotiation handshake specifically includes: Determine the target protocol based on the first target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake and the second target function indicator bit in the performance notification packet in the third interaction process corresponding to the second parameter negotiation handshake; The target data format is determined based on the third target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake and the fourth target function indicator bit in the performance notification packet in the third interaction process corresponding to the second parameter negotiation handshake, or the target data format is determined only based on the third target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake.

9. The parameter negotiation method of the high-speed serial interface according to claim 8, characterized in that: The determining of the target protocol and the target data format based on the result of the first parameter negotiation handshake specifically includes: In the case where the port mode corresponding to the target protocol stack is non-DP / UP mode, determining the target protocol and the target data format based on the fifth target function indicator bit in the performance notification packet in the second interaction process corresponding to the first parameter negotiation handshake; When the port mode corresponding to the target protocol stack is the DP / UP mode, the target protocol and the target data format are determined based on the sixth target function indicator bit in the performance notification packet in the third interaction process corresponding to the first parameter negotiation handshake.

10. The parameter negotiation method of a high-speed serial interface according to claim 1, characterized in that: The method further comprises: When the backdoor selection bit is set, the target protocol and target data format are determined directly based on the local performance parameters pre-configured by the user.

Images