Server high-speed interface protocol self-adaptive switching method and system

Abstract

The invention discloses a server high-speed interface protocol self-adaptive switching method and system, relates to the technical field of server high-speed interfaces, and discloses the server high-speed interface protocol self-adaptive switching method and system. By automatically reading the board card identification data, generating the protocol type judgment data through comparison processing, controlling the switching of the physical switch and initializing the protocol controller, the problems of configuration errors and low efficiency caused by dependence on manual operation in the traditional technology are solved, automatic identification and switching of the server high-speed interface protocol can be realized, manual intervention is not needed, and the efficiency is improved. And the deployment efficiency, the system reliability and the hardware compatibility are obviously improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of server high-speed interface, in particular to a server high-speed interface protocol adaptive switching method and system. BACKGROUND

[0002] In the modern data center environment, the server high-speed interface as the core component of connecting external devices needs to support multiple communication protocols such as PCIe, SAS and XGE, etc. The physical connectors of these interfaces are usually designed in a general form and can be adapted to different functional interface boards, such as optical modules for network transmission or special expansion cards for storage expansion. However, although the physical interfaces have similar appearances, the communication protocols used in the internal interface boards of various types are significantly different, which causes the server to have to accurately identify the board type and configure the corresponding protocol controller to work normally. In the traditional technical solution, the server hardware topology is fixed, and the protocol binding relationship is pre-set. When the interface board is replaced, manual operation is required to complete the configuration adjustment. Specifically, the technical personnel need to manually modify the hardware jumper settings or re-flash the firmware parameters to match the protocol requirements of the newly connected board. Such operation process is complex and time-consuming, and in the batch deployment scenario of server clusters, configuration errors are easily caused by human negligence, resulting in system startup failure or device communication interruption. At the same time, the automatic operation and maintenance system requires the hardware to have the plug-and-play capability, but the existing method lacks the automatic reading of the board identification and the intelligent judgment mechanism of the protocol type, and cannot realize the dynamic switching of the physical signal path. This not only significantly prolongs the hardware deployment period and increases the difficulty of operation and maintenance management, but also restricts the flexible scheduling and compatibility protection of hardware resources in the data center. Especially in the server power-on startup phase, if the protocol adaptation cannot be completed in time, it will directly hinder the subsequent device initialization process and affect the overall system reliability.

[0003] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0004] The main purpose of the present application is to provide a server high-speed interface protocol adaptive switching method and system, aiming to improve the deployment efficiency, system reliability and hardware compatibility.

[0005] To achieve the above purpose, the present application provides a server high-speed interface protocol adaptive switching method, which comprises: After the server is powered on and started, the programmable logic device reads the board identification data from the identification circuit of the interface board connected to the server high-speed physical interface; The board identification data is transmitted to the BIOS, and the board identification data is compared and processed with the pre-stored identification-protocol mapping table in the BIOS to obtain protocol type judgment data; According to the protocol type determination data, the BIOS generates corresponding switching control instruction data; The switching control instruction data is sent to the programmable logic device to control a multiplexer inside the programmable logic device to perform physical switch switching, and protocol switching result data is obtained; Based on the protocol type determination data and the protocol switching result data, the BIOS performs initialization processing on the corresponding protocol controller to complete adaptive switching of the server high-speed interface protocol.

[0006] In an embodiment, after the server is powered on, the step of reading the board card identification data from the identification circuit of the interface board connected to the server high-speed physical interface by the programmable logic device includes: The connection state of the interface board is detected by the programmable logic device to obtain connection state detection data; Based on the connection state detection data, the programmable logic device reads resistance network state data from the identification circuit of the interface board; The resistance network state data is converted into a binary encoding format to generate the board card identification data.

[0007] In an embodiment, the step of reading the resistance network state data from the identification circuit of the interface board by the programmable logic device includes: The communication interface of the programmable logic device is connected to the identification circuit of the interface board; Based on the communication connection, the programmable logic device reads the resistance voltage dividing network state in the identification circuit; The resistance voltage dividing network state is converted into voltage value data; The voltage value data is mapped into a binary encoding format to generate the resistance network state data.

[0008] In an embodiment, the step of comparing the board card identification data with the pre-stored identification-protocol mapping table in the BIOS to obtain protocol type determination data includes: The board card identification data is transmitted from the programmable logic device to the BIOS through the system management bus; The received board card identification data is matched with the pre-stored board card identification data in the identification-protocol mapping table in the BIOS to obtain matching result data; According to the matching result data, the corresponding protocol type is determined to generate the protocol type determination data.

[0009] In an embodiment, the step of matching the received board identification data with the pre-stored board identification data in the identification-protocol mapping table in the BIOS to obtain matching result data includes: reading the identification-protocol mapping table from the non-volatile storage area of the BIOS to obtain mapping table data; comparing the board identification data with each pre-stored board identification data in the mapping table data one by one; when the board identification data is consistent with any pre-stored board identification data, generating matching success data as the matching result data; when the board identification data is inconsistent with all pre-stored board identification data, generating matching failure data as the matching result data.

[0010] In an embodiment, the step of generating corresponding switching control instruction data by the BIOS according to the protocol type determination data includes: determining the target protocol controller type that needs to be activated according to the protocol type determination data to obtain target controller type data; generating signal path configuration parameters corresponding to the target protocol controller based on the target controller type data; encapsulating the signal path configuration parameters into a command format that can be recognized by the programmable logic device to generate the switching control instruction data.

[0011] In an embodiment, the step of controlling the multiplexer inside the programmable logic device to perform physical switch switching to obtain protocol switching result data includes: sending the switching control instruction data from the BIOS to the programmable logic device through the system management bus; parsing the switching control instruction data in the programmable logic device to extract multiplexer control parameters; based on the multiplexer control parameters, sending switch control signals to the control port of the multiplexer; controlling the switch array inside the multiplexer to perform switching operation through the switch control signals to connect the signal channel of the high-speed physical interface to the signal output end of the corresponding protocol controller; detecting the connection state of the path after switching to generate the protocol switching result data.

[0012] In an embodiment, the step of controlling the switch array inside the multiplexer to perform switching operation through the switch control signals includes: determining the target signal path that needs to be connected and the original signal path that needs to be disconnected according to the multiplexer control parameters; generating a switch array control signal sequence; controlling, according to a timing of the switch array control signal sequence, a crosspoint switch matrix inside the multiplexer to establish a new signal connection path; disconnecting the original signal path; verifying a connection state of the new signal connection path to obtain path verification data.

[0013] In an embodiment, based on the protocol type determination data and the protocol switching result data, the step of initializing the corresponding protocol controller by the BIOS includes: determining a protocol controller type that needs to be initialized according to the protocol type determination data to obtain controller type data to be initialized; based on the controller type data to be initialized, loading a corresponding protocol controller driver from a storage area of the BIOS; according to the protocol switching result data, using the loaded protocol controller driver to configure registers and set parameters of the protocol controller; verifying an initialization state of the protocol controller to obtain initialization completion state data; based on the initialization completion state data, completing the initialization processing of the protocol controller.

[0014] In addition, to achieve the above-mentioned purpose, the application further provides a server high-speed interface protocol adaptive switching system, which comprises a memory, a processor, and a server high-speed interface protocol adaptive switching program stored in the memory and capable of running on the processor, and the server high-speed interface protocol adaptive switching program is configured to implement the steps of the server high-speed interface protocol adaptive switching method.

[0015] The server high-speed interface protocol adaptive switching method and system provided by the application solve the configuration errors and low efficiency caused by manual operation in the prior art by automatically reading card identification data, comparing and processing to generate protocol type determination data, controlling physical switch switching and initializing protocol controllers, can realize automatic identification and switching of server high-speed interface protocols, without manual intervention, and significantly improve deployment efficiency, system reliability and hardware compatibility. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application.

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without any creative effort.

[0018] Figure 1 The flowchart provided by an embodiment of the server high-speed interface protocol adaptive switching method of the present application; Figure 2 The structural diagram provided by an embodiment of the server high-speed interface protocol adaptive switching system of the present application.

[0019] Explanation of reference numerals: 10, memory; 20, processor.

[0020] The object implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0021] The technical solutions in the present application will be described clearly and completely in the present application with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. The components of the present application described and shown in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without any creative effort are within the scope of protection of the present application.

[0022] It should be understood that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. Meanwhile, in the description of the present application, the terms "first", "second", etc. are only used for differentiation, and cannot be understood as indicating or implying relative importance.

[0023] In the prior art, when the server high-speed interface adapts to different types of interface boards, fixed hardware topology or manual configuration is often used. These methods are tedious and prone to errors, and it is difficult to achieve flexible, reliable and plug-and-play adaptive switching, resulting in low deployment efficiency, increased operation and maintenance costs, and being unable to meet the needs of dynamic deployment of hardware resources and automatic identification of compatibility in modern data centers.

[0024] Based on this, the embodiments of the present application provide a server high-speed interface protocol adaptive switching method, which is described with reference to Figure 1The server high-speed interface protocol adaptive switching method includes steps S100 to S500, wherein: Step S100: After the server is powered on, the board identification data is read from the identification circuit of the interface board connected to the high-speed physical interface of the server through the programmable logic device. Step S200: The board identification data is transmitted to the input / output system BIOS. In the BIOS, the board identification data is compared with the pre-stored identifier-protocol mapping table to obtain protocol type determination data. Step S300: Determine the data based on the protocol type and generate corresponding switching control command data through the BIOS; Step S400: Send the switching control command data to the programmable logic device to control the multiplexer inside the programmable logic device to perform physical switch switching and obtain protocol switching result data; Step S500: Based on the protocol type determination data and the protocol switching result data, the BIOS performs initialization processing on the corresponding protocol controller to complete the adaptive switching of the server's high-speed interface protocol.

[0025] In this embodiment, the server high-speed physical interface refers to the high-speed communication interface on the server used to connect external devices or storage devices, such as standard interfaces like PCIe, SAS, and XGE, which typically take the form of a slot or connector. The interface board refers to an expansion card or module inserted into the server's high-speed physical interface. It integrates specific functional circuits and communication protocol support to expand the server's functionality or connect specific types of external devices. The identification circuit refers to the circuit on the interface board used to store or generate its own unique identification information. This circuit can be a simple resistor network, EEPROM, or other readable storage unit. Board identification data refers to the digital information read from the interface board's identification circuit that uniquely identifies the interface board's type or function. The programmable logic device (PLD) refers to an integrated circuit whose internal logic functions can be configured through programming, such as an FPGA or CPLD. In this embodiment, it is used to communicate with the interface board and control physical switching.

[0026] In this embodiment, the Basic Input / Output System (BIOS) refers to the firmware program that runs when the server starts up. It is responsible for tasks such as hardware initialization, self-test, and operating system loading. In this embodiment, it is used to process board identification data, generate control commands, and initialize the protocol controller. The identifier-protocol mapping table is a data structure stored in the BIOS or other non-volatile memory areas, recording the association between different board identification data and their corresponding high-speed interface protocol types. Protocol type determination data refers to the communication protocol type information that the interface board supports or should use, determined by the BIOS after comparing the board identification data with the identifier-protocol mapping table.

[0027] In this embodiment, the switching control command data refers to the command generated by the BIOS based on the protocol type determination data and sent to the programmable logic device (PLD), which instructs the PLD to perform a physical signal path switching operation. A multiplexer is an electronic switch capable of selecting an input signal based on a control signal and connecting it to its output. In this embodiment, it is used to switch physical signal paths between different high-speed interface protocol controllers. Protocol switching result data refers to the information fed back to the BIOS by the PLD after performing the multiplexer switching operation, regarding whether the switching operation was successful and the current path connection status. A protocol controller is a hardware module or IP core within the server used to implement specific high-speed communication protocols (such as PCIe controllers, SAS controllers, etc.), responsible for handling the physical layer, data link layer, and other functions of the corresponding protocol.

[0028] In this embodiment, after the server powers on, it needs to obtain the identification information of the interface board. One implementation method is to use a programmable logic device (PLD) to communicate with the interface board connected to the server's high-speed physical interface and read the board identification data from the interface board's identification circuit. For example, the PLD can periodically poll specific registers on the interface board to obtain preset board model or version information. Alternatively, the interface board's identification circuit can be a simple jumper setting, where the PLD generates board identification data by detecting the jumper's open / closed state.

[0029] In this embodiment, after obtaining the board identification data, this data needs to be transmitted to the Input / Output System (BIOS) for processing. Specifically, the programmable logic device (PLC) can send the read board identification data to the BIOS via a general-purpose interface (e.g., GPIO or SPI). In the BIOS, the received board identification data is compared with a pre-stored identifier-protocol mapping table. This mapping table can be a simple lookup table that lists the correspondence between known board identifiers and their corresponding protocol types. The BIOS traverses this mapping table to find the entry that matches the received board identification data, thereby obtaining the protocol type determination data that the interface board should use. For example, if the board identification data is "0x01", and the mapping table indicates that "0x01" corresponds to the PCIe protocol, then the protocol type determination data is PCIe.

[0030] In this embodiment, based on the obtained protocol type determination data, the BIOS needs to generate corresponding switching control command data. As one implementation, the BIOS can select a template matching the protocol type from its internally stored preset command templates based on the protocol type determination data. For example, if the protocol is determined to be PCIe, the BIOS selects the control command template corresponding to the PCIe protocol. Subsequently, the BIOS fills this template with specific switching control command data, which includes the parameters required for the programmable logic device to perform a physical switch.

[0031] In this embodiment, the generated switching control command data is then sent to the programmable logic device (PLD). Upon receiving the command, the PLD controls its internal multiplexer to perform a physical switch according to the command content. For example, the multiplexer can be an array of multiple relays or analog switches. The PLD controls the on / off state of these relays to connect the signal path of the server's high-speed physical interface to a specific protocol controller. After the switch is completed, the PLD detects the connection status of the current signal path and feeds back this status information as protocol switching result data to the BIOS.

[0032] In this embodiment, based on protocol type determination data and protocol switching result data, the BIOS performs initialization processing on the corresponding protocol controller. Specifically, the BIOS identifies the protocol controller that needs to be activated and configured within the server based on the protocol type determination data. For example, if the protocol is determined to be SAS, the BIOS will prepare to initialize the SAS controller. Simultaneously, the BIOS will refer to the protocol switching result data to confirm that the physical path is correctly connected. Subsequently, the BIOS will perform a series of initialization operations, such as loading the corresponding driver, configuring the protocol controller's registers, and setting operating parameters, to ensure that the protocol controller can function normally, thereby completing the adaptive switching of the server's high-speed interface protocol.

[0033] In this embodiment, the interface board identifier is automatically read when the server powers on, and the BIOS intelligently compares the mapping table and generates a switching instruction, thereby controlling the programmable logic device to switch physical paths and finally initializing the corresponding protocol controller. This achieves adaptive switching of the server's high-speed interface protocol, effectively solving the problems of cumbersome manual configuration, error-proneness, and low deployment efficiency in traditional solutions. It also improves the server's plug-and-play capability and compatibility with different protocol interface boards, meeting the needs of modern data centers for dynamic allocation of hardware resources and automated operation and maintenance.

[0034] In one feasible implementation, after the server is powered on, the step of reading board identification data from the identification circuit of the interface board connected to the high-speed physical interface of the server via a programmable logic device includes: detecting the connection status of the interface board via the programmable logic device to obtain connection status detection data; based on the connection status detection data, reading resistor network status data from the identification circuit of the interface board via the programmable logic device; and converting the resistor network status data into a binary encoding format to generate the board identification data.

[0035] In this embodiment, a programmable logic device (PLD) is used to detect the connection status of the interface board and acquire connection status detection data. This aims to ensure that the interface board is correctly connected and in an operable state before attempting to read the identification data. The PLD can determine the connection status of the interface board by monitoring the level changes of specific pins on the high-speed physical interface (e.g., presence detection pins or hot-plug detection signals). When the interface board is inserted, the levels of these pins will change according to a preset pattern, and the PLD will generate connection status detection data accordingly to indicate whether the interface board is connected.

[0036] In this embodiment, based on connection status detection data, a programmable logic device (PLD) reads resistor network status data from the identification circuitry on the interface board. Once the interface board is confirmed to be connected, the PLD interacts with the identification circuitry on the interface board. The identification circuitry typically consists of one or more resistors that encode a unique identifier for the board in a specific configuration (e.g., a voltage divider network or pull-up / pull-down resistors). The PLD can acquire resistor network status data, reflecting the electrical characteristics of the resistor network, either by applying a known voltage to the identification circuitry and measuring the corresponding current, or by reading the voltage value at a specific pin.

[0037] Subsequently, in this embodiment, the resistor network status data is converted into a binary encoding format to generate board identification data. Since the raw data read from the resistor network is typically analog (such as voltage values) or non-standard digital, the logic circuitry within the programmable logic device (e.g., an analog-to-digital converter or comparator) parses and converts this raw data into a standard binary encoding format. For example, different voltage ranges can be mapped to different binary bits, forming a unique binary sequence, i.e., board identification data. This conversion enables the identification data to be accurately identified and processed by the BIOS system.

[0038] In this embodiment, the above technical solution first detects the connection status of the interface board, effectively avoiding invalid or erroneous identification data reading operations when the interface board is not correctly connected, thus improving the robustness of the system. Secondly, using a resistor network as the identification circuit provides a passive and reliable board identification encoding method with strong anti-interference capabilities and relatively low implementation cost. Finally, the resistor network status data is converted into a standard binary encoding format, ensuring the accuracy and processability of the board identification data and providing reliable input for subsequent identification-protocol mapping comparison by the BIOS. This step-by-step and refined data acquisition and processing mechanism significantly improves the accuracy and reliability of adaptive switching of high-speed interface protocols on the server.

[0039] In one feasible implementation, the step of reading resistor network status data from the identification circuit of the interface board via the programmable logic device includes: establishing a communication connection between the programmable logic device and the identification circuit of the interface board through the communication interface of the programmable logic device; reading the resistor voltage divider network status in the identification circuit via the programmable logic device based on the communication connection; converting the resistor voltage divider network status into voltage value data; and mapping the voltage value data into a binary encoding format to generate the resistor network status data.

[0040] In this embodiment, establishing a communication connection between the programmable logic device's communication interface and the identification circuit on the interface board means that the programmable logic device uses its built-in or external communication module (e.g., serial communication interfaces such as I2C, SPI, UART, or a custom parallel interface) to physically and logically connect with the identification circuit on the interface board. This communication interface is responsible for data transmission and control signal exchange, ensuring that the programmable logic device can send read commands to the identification circuit and receive the returned data. For example, the programmable logic device can act as a master device, sending an address and read command to the identification circuit via the I2C bus, and the identification circuit, acting as a slave device, responds and provides data.

[0041] In this embodiment, reading the state of the resistor divider network in the identification circuit via the programmable logic device (PLD) based on the communication connection means that after the communication connection is established, the PLD sends a specific read command to the identification circuit through its communication interface to obtain the current state of the resistor divider network in the identification circuit. The identification circuit typically contains one or more resistor divider networks, and their output voltage values ​​vary depending on the specific configuration of the interface board (e.g., different board models, functional versions, etc.). The PLD obtains the original physical identification information by reading these analog voltage values. For example, the PLD can control a multiplexer to connect sequentially to the output terminals of different resistor divider networks in the identification circuit and read their voltages.

[0042] In this embodiment, converting the resistor divider network state into voltage value data means that the analog resistor divider network state (i.e., the analog voltage signal) read from the identification circuit is converted into digital voltage value data by an analog-to-digital converter (ADC). This ADC can be an ADC module integrated within a programmable logic device or an externally connected independent ADC chip. The conversion process includes sampling, quantizing, and encoding the analog voltage signal to obtain a series of discrete digital values ​​that accurately reflect the magnitude of the original analog voltage. For example, a 10-bit ADC can convert an analog voltage of 0-3.3V into a digital value of 0-1023.

[0043] In this embodiment, mapping the voltage value data to a binary encoding format to generate the resistor network status data refers to converting the voltage value data obtained through analog-to-digital conversion into a binary encoding format with specific meaning according to preset mapping rules. These mapping rules are typically stored in the internal memory of the programmable logic device or are embedded in the logic circuit during design. For example, if a certain voltage range (e.g., 0.5V-1.0V) corresponds to binary code "00", and another voltage range (e.g., 1.5V-2.0V) corresponds to binary code "01", the programmable logic device will look up or calculate the corresponding binary code based on the read voltage value data. The final generated binary code is the resistor network status data, which serves as a unique digital identifier for the interface board.

[0044] In this embodiment, establishing a communication connection between the programmable logic device and the interface board identification circuit ensures the reliability of data reading. Furthermore, by reading the resistor divider network state and converting it into voltage value data, the analog physical quantity is digitized, effectively avoiding the problem of analog signals being susceptible to interference. Finally, the voltage value data is mapped into a binary encoding format, generating standardized resistor network state data. This provides accurate and stable input for subsequent board identification data comparison, improving the accuracy and robustness of the server's high-speed interface protocol adaptive switching.

[0045] In one feasible implementation, the step of comparing the board identification data with a pre-stored identifier-protocol mapping table in the BIOS to obtain protocol type determination data includes: transmitting the board identification data from the programmable logic device to the BIOS via the system management bus; matching the received board identification data with the pre-stored board identification data in the identifier-protocol mapping table in the BIOS to obtain matching result data; and determining the corresponding protocol type based on the matching result data to generate the protocol type determination data.

[0046] In this embodiment, transmitting the board identification data from the programmable logic device (PLD) to the BIOS via the System Management Bus (SMBus) means using the SMBus as a communication medium to transmit the board identification data read by the PLD to the BIOS. The SMBus is a low-speed serial bus widely used in computer systems for management and control functions, allowing the main processor (via the BIOS) to communicate with various peripheral devices (such as PLDs) to read status, configure parameters, or send control commands. In this step, the PLD acts as a slave device on the SMBus, and the BIOS acts as the master device. After reading the board identification data, the PLD stores it in internal registers. The BIOS sends read commands to specific addresses of the PLD via the SMBus protocol to read the board identification data from these registers. This transmission method ensures the reliability of data on the low-speed management channel and avoids impacting high-speed data paths.

[0047] Furthermore, in this embodiment, the process of matching the received board identifier data with the pre-stored board identifier data in the identifier-protocol mapping table in the BIOS to obtain matching result data means that after receiving the board identifier data, the BIOS accesses its internally stored identifier-protocol mapping table. This identifier-protocol mapping table is a data structure pre-stored in the BIOS's accessible storage area, defining the relationship between different board identifiers and their corresponding high-speed interface protocol types. The BIOS traverses this mapping table, comparing the received board identifier data with each pre-stored board identifier data in the table. If a match is found, it indicates that the board type is known and the corresponding protocol type can be obtained; in this case, a successful match is generated as the matching result data. If no match is found after traversing the entire table, it may indicate that the board type is unknown or not supported; in this case, a failed match is generated as the matching result data.

[0048] Based on this, in this embodiment, determining the corresponding protocol type and generating the protocol type determination data according to the matching result data means that if the matching result data shows a successful match, the BIOS will extract the protocol type information associated with the matching board identifier data from the identifier-protocol mapping table, such as PCIe, UPI, CXL, etc., and use it as the protocol type determination data. If the matching result data shows a failed match, the BIOS can adopt a preset default protocol type, such as falling back to PCIe Gen3, or generate determination data indicating an unknown protocol type so that the system can perform error handling or prompts. The protocol type determination data can be an enumeration value, a string, or a bitmask, depending on the system design.

[0049] In this embodiment, through the above technical solution, after the server powers on, the board identification data read by the programmable logic device can be efficiently and reliably transmitted to the BIOS. The system management bus, as a mature and stable communication mechanism, ensures the accuracy and integrity of the board identification data transmission. After receiving the board identification data, the BIOS performs precise matching with a pre-stored identifier-protocol mapping table to quickly and accurately determine the high-speed interface protocol type supported by the interface board, thereby generating reliable protocol type determination data. This explicit data transmission and comparison mechanism avoids protocol switching failures or performance degradation caused by data transmission errors or inaccurate protocol type determination, providing a solid foundation for subsequent physical switch switching and protocol controller initialization, and significantly improving the efficiency and reliability of adaptive switching of the server's high-speed interface protocols.

[0050] In one feasible implementation, the step of matching the received board identification data with the pre-stored board identification data in the identifier-protocol mapping table in the BIOS to obtain the matching result data includes: reading the identifier-protocol mapping table from the non-volatile storage area of ​​the BIOS to obtain the mapping table data; comparing the board identification data with each pre-stored board identification data in the mapping table data one by one; when the board identification data matches any pre-stored board identification data, generating successful matching data as the matching result data; when the board identification data does not match any of the pre-stored board identification data, generating failed matching data as the matching result data.

[0051] In this embodiment, the non-volatile storage area of ​​the BIOS typically refers to storage media such as flash memory or EEPROM inside the BIOS chip. These storage media can still retain data after the server is powered off. The operation of reading the identifier-protocol mapping table from this area is executed by the BIOS firmware code, which obtains the stored mapping table data by accessing specific memory addresses or registers. This storage method ensures the persistence and reliability of the mapping table; even if the server is powered off, the mapping table will not be lost, ensuring that the system can obtain the correct mapping relationship every time it starts up.

[0052] In this embodiment, after obtaining the mapping table data, the board identification data is compared one by one with each pre-stored board identification data in the mapping table. This is typically a loop or iterative process, where the BIOS firmware traverses each record in the mapping table. For each record, its pre-stored board identification data is extracted and then compared with the currently read board identification data. This comparison can be a bit-to-bit comparison, a string comparison, or a hash value comparison, depending on the format of the board identification data. This one-by-one comparison method ensures that all known board types can be comprehensively checked to find the correct match.

[0053] In this embodiment, during the comparison process, once the board identification data is found to match any pre-stored board identification data in the mapping table, the comparison stops, and a specific data indicating a successful match is generated as the matching result data. This successful match data can be a Boolean value (such as True), a specific status code, or an index or pointer directly pointing to the matched mapping table entry, clearly indicating that the board type has been identified and providing a basis for subsequent protocol type determination. Conversely, if no pre-stored board identification data matching the board identification data is found after traversing the entire mapping table, a specific data indicating a failed match is generated as the matching result data. This failed match data can be a Boolean value (such as False), a specific error code, or a null value, clearly indicating that the board type is unknown. The system can then take measures such as default processing, error reporting, or entering safe mode to avoid abnormal system behavior due to unknown boards.

[0054] In this embodiment, by storing the identifier-protocol mapping table in the non-volatile storage area of ​​the BIOS using the above technical solution, the persistence and reliability of the mapping table are ensured, avoiding data loss after server power failure. By comparing the board identifier data with the pre-stored board identifier data in the mapping table one by one, the type of the connected interface board can be comprehensively and accurately identified. Simultaneously, by clearly distinguishing between successful and unsuccessful matching results, the system can generate accurate matching result data based on the actual situation, thus providing a solid foundation for subsequent protocol type determination and improving the accuracy and robustness of adaptive protocol switching.

[0055] In one feasible implementation, the step of generating corresponding switching control command data through the BIOS based on the protocol type determination data includes: determining the target protocol controller type to be activated based on the protocol type determination data, and obtaining target controller type data; generating signal path configuration parameters corresponding to the target protocol controller based on the target controller type data; and encapsulating the signal path configuration parameters into a command format that the programmable logic device can recognize to generate the switching control command data.

[0056] In this embodiment, determining the target protocol controller type to be activated based on protocol type determination data, and obtaining the target controller type data, means that after receiving the protocol type determination data, the BIOS will identify the protocol types supported by the current interface board, such as PCIe, SAS, SATA, etc. The BIOS can pre-store a mapping table that associates various protocol types with the corresponding specific protocol controllers on the server motherboard (e.g., PCIe controller A, SAS controller B, etc.). By querying this mapping table, the BIOS can accurately determine which protocol controller is the target that needs to be activated and configured, and obtain its corresponding target controller type data. This step is the basis for subsequently generating precise switching instructions, ensuring the targeted nature of the instructions.

[0057] In this embodiment, generating signal path configuration parameters corresponding to the target protocol controller based on the target controller type data means that after determining the target controller type, the BIOS extracts or calculates the parameters used to configure the multiplexer to establish the correct signal path from its internally stored configuration information. These parameters may include specific port connection relationships of the multiplexer's internal switch array, signal line polarity settings, clock synchronization mode, data rate mode, and other electrical or logical configurations related to the signal transmission of a specific protocol. For example, for the PCIe protocol, it may be necessary to configure the multiplexer to connect the differential signal lines of the high-speed physical interface to a specific lane of the PCIe controller; for the SAS protocol, it may be connected to the corresponding port of the SAS controller. These parameters are crucial to ensuring correct signal transmission and proper protocol operation.

[0058] In this embodiment, encapsulating the signal path configuration parameters into a command format recognizable by the programmable logic device (PLD) to generate switching control instruction data means that the BIOS formats and encodes the generated signal path configuration parameters according to the programming interface specification or communication protocol requirements of the PLD (e.g., FPGA, CPLD). PLDs typically receive control instructions via specific register writes or serial communication protocols (e.g., SPI, I2C). Therefore, the BIOS packages the configuration parameters into a series of binary or specific format commands that the PLD can directly understand and execute. This may include adding command headers, checksums, address information, etc., ultimately forming a complete, executable switching control instruction data packet. For example, if the PLD receives instructions via the I2C bus, the BIOS packages the configuration parameters into a series of I2C write operation commands, specifying the target register address and the data to be written.

[0059] In this embodiment, through the above technical solution, during the adaptive switching of the server's high-speed interface protocol, the BIOS can determine the data based on the protocol type, first clearly identifying the target protocol controller type to be activated, thereby avoiding blind or erroneous instruction generation. Based on this, it further generates signal path configuration parameters that precisely match the target protocol controller, ensuring that the multiplexer can accurately connect the signal channels of the high-speed physical interface to the correct protocol controller and perform appropriate signal configuration when performing physical switch switching. Finally, these refined configuration parameters are encapsulated into a command format that can be recognized by programmable logic devices, making the switching control instruction data highly targeted and executable. This significantly improves the accuracy and reliability of the multiplexer's physical switch switching, effectively avoiding switching failures or system instability caused by ambiguous instructions or configuration errors, thereby ensuring the success rate of the server's high-speed interface protocol adaptive switching and the stability of system operation.

[0060] In one feasible implementation, the steps of controlling the multiplexer inside the programmable logic device to perform physical switch switching and obtain protocol switching result data include: sending the switching control command data from the BIOS to the programmable logic device via the system management bus; parsing the switching control command data in the programmable logic device to extract the multiplexer control parameters; sending a switch control signal to the control port of the multiplexer based on the multiplexer control parameters; controlling the switch array inside the multiplexer to perform a switching operation through the switch control signal, connecting the signal channel of the high-speed physical interface to the signal output terminal of the corresponding protocol controller; detecting the path connection status after switching, and generating the protocol switching result data.

[0061] In this embodiment, the switching control command data is first sent from the BIOS to the programmable logic device (PLD) via the System Management Bus (SMBus). The SMBus is a low-speed serial communication bus widely used in server motherboards, designed to facilitate communication between various management chips on the motherboard and the BIOS. Here, the BIOS acts as the SMBus master, encapsulating the generated switching control command data into data packets conforming to the SMBus protocol and sending them through the SMBus interface. The PLD (e.g., FPGA or CPLD) acts as the SMBus slave, integrating an SMBus interface module to receive and buffer these data packets. This communication method offers good compatibility and stability, ensuring reliable transmission of switching command data from the BIOS to the PLD, providing accurate control information for subsequent physical switching operations.

[0062] In this embodiment, the switching control instruction data is then parsed in the programmable logic device (PLD) to extract the multiplexer control parameters. After receiving the switching control instruction data, the PLD needs to parse it to understand its specific meaning. For this purpose, the PLD has a dedicated instruction parsing logic module. This module decodes the received raw data according to a predefined instruction format (e.g., including instruction header, instruction type, target multiplexer ID, and specific control parameter fields). Through parsing, key parameters for controlling the multiplexer can be accurately extracted from the instruction data, such as the target protocol channel selection code, the configuration bitmap of the switch array, or specific switching timing requirements. These extracted multiplexer control parameters are the direct basis for driving the multiplexer to perform physical switching.

[0063] In this embodiment, based on the multiplexer control parameters, switch control signals are sent to the multiplexer's control port. After the multiplexer control parameters are successfully extracted, the control logic inside the programmable logic device (PLD) generates corresponding switch control signals based on these parameters. These signals are level or pulse sequences that the multiplexer can directly recognize and respond to. For example, if the multiplexer uses digital selection inputs, the control parameters are converted into corresponding binary selection signals and sent to the multiplexer's selection control port through the PLD pins of the PLD. These switch control signals directly determine the on / off state of the multiplexer's internal switch array and are the driving force for physical path switching.

[0064] In this embodiment, the switch array inside the multiplexer is further controlled by a switch control signal to perform switching operations, connecting the signal channel of the high-speed physical interface to the signal output of the corresponding protocol controller. The multiplexer contains a switch array composed of multiple analog or digital switches. When a switch control signal is received from the programmable logic device, the switch array performs precise on / off operations according to the signal state. Specifically, the signal channel of the high-speed physical interface (e.g., high-speed differential signal lines such as PCIe, SAS, or SATA) serves as the input of the multiplexer, while the signal outputs of different types of protocol controllers inside the server (such as PCIe controllers, SAS controllers, etc.) serve as different output options for the multiplexer. Through precise control of the switch control signal, the multiplexer can switch the signal channel of the high-speed physical interface from its current connection state to a state connected to the target protocol controller, thereby establishing a new high-speed data path at the physical layer.

[0065] In this embodiment, the final step is to detect the connection status of the switched path and generate protocol switching result data. After the multiplexer completes the physical switching operation, the connection status of the switched path needs to be detected to ensure the effectiveness and correctness of the switching. Programmable logic devices can integrate a path status detection module to verify this in various ways. For example, they can monitor key signal levels and signal integrity indicators (such as eye diagram quality) on the high-speed signal channel after the switch, or detect specific handshake signals that the protocol controller may send after the connection is established. Furthermore, some multiplexers may provide status feedback pins or registers indicating the currently selected channel, which the programmable logic device can read. The detection results, such as a switching success / failure flag, the currently connected channel identifier, or any detected error codes, will be encapsulated into protocol switching result data and can be sent back to the BIOS as the basis for subsequent protocol controller initialization processing.

[0066] In this embodiment, through the above technical solution, the server high-speed interface protocol adaptive switching method can reliably transmit the switching control command data to the programmable logic device (PLD) via the system management bus. The PLD precisely parses the command, extracts the multiplexer control parameters, and generates a switch control signal accordingly. This precisely controls the physical switching of the switch array within the multiplexer, accurately connecting the signal channel of the high-speed physical interface to the target protocol controller. Furthermore, by detecting the connection status of the switched path, protocol switching result data can be obtained in a timely manner, providing accurate feedback for subsequent protocol controller initialization in the BIOS. This effectively avoids protocol switching failures caused by inaccurate or unverifiable physical connection switching, significantly improving the reliability and success rate of server high-speed interface protocol adaptive switching.

[0067] In one feasible implementation, the step of controlling the switch array inside the multiplexer to perform switching operations via the switch control signal includes: determining the target signal path to be connected and the original signal path to be disconnected according to the multiplexer control parameters; generating a switch array control signal sequence; controlling the cross-point switch matrix inside the multiplexer to establish a new signal connection path according to the timing of the switch array control signal sequence; disconnecting the original signal path; verifying the connection status of the new signal connection path and obtaining path verification data.

[0068] In this embodiment, upon receiving the multiplexer control parameters, the programmable logic device (PLD) analyzes these parameters to determine the specific physical signal path corresponding to the protocol to be activated, i.e., the target signal path. Simultaneously, if a connection to a previous protocol exists, the existing signal path that needs to be disconnected is also identified. This process ensures that the switching operation has a clear physical connection target, avoiding erroneous connections that might result from blind switching. For example, for an interface board supporting both PCIe and Ethernet protocols, when the multiplexer control parameters indicate a switch to the PCIe protocol, the PLD identifies the differential signal pairs and clock signal lines required by the PCIe protocol as the target signal path, and identifies the signal lines used by the Ethernet protocol as the existing signal path.

[0069] In this embodiment, once the target signal path and the existing signal path are determined, the programmable logic device generates a series of precise switch array control signal sequences based on the internal structure and timing requirements of the multiplexer. This sequence defines the opening and closing order of each switch unit within the multiplexer, as well as the corresponding time delays. For example, to avoid signal short circuits or transient interference during switching, some switches in the existing path may be disconnected first, followed by a brief stabilization period before closing the critical switches in the new path, and finally disconnecting the remaining switches in the existing path. This fine-grained timing control is crucial for maintaining the integrity of high-speed signals.

[0070] In this embodiment, the multiplexer typically includes a crosspoint switch matrix, which consists of multiple independently controllable switch units, enabling flexible connection of any input port to any output port. The programmable logic device precisely controls the corresponding switch units in the crosspoint switch matrix according to the timing sequence of a pre-generated switch array control signal sequence. By activating or deactivating specific switches, a new physical connection path conforming to the target protocol is established between the signal channel of the high-speed physical interface and the signal input / output terminals of the corresponding protocol controller. For example, when switching to the PCIe protocol, the crosspoint switch matrix connects the PCIe differential signal lines of the high-speed physical interface to the corresponding pins of the PCIe protocol controller according to the control signals.

[0071] In this embodiment, the programmable logic device ensures that all signal connection paths related to the original protocol are disconnected simultaneously with or immediately after establishing a new signal connection path. This step is necessary to prevent potential interference, signal reflection, or impedance mismatch issues between the old and new signal paths. By explicitly disconnecting the original paths, it ensures that the newly established signal path is unique and clean, thus providing a clean physical environment for subsequent protocol communication. For example, when switching from Ethernet to PCIe, all signal lines previously connected to the Ethernet protocol controller are disconnected.

[0072] In this embodiment, after the physical switch is switched, the programmable logic device performs a verification operation to confirm whether the new signal connection path has been correctly established and is in a stable state. This can be achieved in various ways, such as reading the status register inside the multiplexer to check the actual state of the switch, or confirming the validity of the connection by detecting the level or impedance of a specific signal line. The verification result is acquired as path verification data, which can be fed back to the BIOS for subsequent protocol controller initialization or error handling. For example, it can be detected whether the voltage at a specific test point on the new connection path meets expectations, or the path can be confirmed to be conductive through a simple handshake signal.

[0073] In this embodiment, the above technical solution enables fine-grained control and verification of the internal switch array of the multiplexer during the adaptive switching of the server's high-speed interface protocol. By clearly identifying the target and the original signal path and generating a switch array control signal sequence with precise timing, it ensures that the cross-point switch matrix avoids transient interference and signal integrity issues when establishing new signal connection paths. Simultaneously, actively disconnecting the original signal path eliminates potential signal conflicts and crosstalk. More importantly, verifying the connection status of the newly established signal path provides reliable confirmation of the physical switching result, significantly improving the accuracy, stability, and reliability of high-speed interface protocol switching. This effectively avoids data transmission errors or system instability caused by physical connection problems, providing a solid foundation for the subsequent initialization of the protocol controller.

[0074] In one feasible implementation, the step of initializing the corresponding protocol controller through the BIOS based on the protocol type determination data and the protocol switching result data includes: determining the type of protocol controller to be initialized according to the protocol type determination data, and obtaining the controller type data to be initialized; loading the corresponding protocol controller driver from the storage area of ​​the BIOS based on the controller type data to be initialized; configuring the registers and setting the parameters of the protocol controller using the loaded protocol controller driver according to the protocol switching result data; verifying the initialization status of the protocol controller and obtaining initialization completion status data; and completing the initialization process of the protocol controller based on the initialization completion status data.

[0075] In this embodiment, the protocol type determination data is obtained by the BIOS by comparing the board identification data with a pre-stored mapping table, which clarifies the high-speed interface type supported by the current interface board. Based on this determination data, the BIOS identifies the specific hardware protocol controller module on the server motherboard or integrated in the chipset. This module is responsible for handling the physical layer and data link layer functions of the corresponding protocol. The BIOS then obtains the controller type data to be initialized, i.e., generates an identifier or parameter for precise location and operation of the specific protocol controller in subsequent steps. This ensures the specificity of the initialization process. For example, the BIOS can maintain a mapping table between protocol types and controller hardware addresses or register base addresses. When the protocol type determination data is received, the BIOS queries this mapping table to obtain the controller hardware resource information corresponding to the protocol type and encapsulates it as the controller type data to be initialized.

[0076] In this embodiment, the protocol controller driver is a software module that operates and configures specific protocol controller hardware. These drivers are typically pre-stored in the BIOS's non-volatile memory area to ensure hardware initialization before the operating system loads. Loading the driver involves reading this software code and configuration data from the storage area into the BIOS's runtime memory, making it executable by the BIOS. This step is fundamental to implementing protocol controller functionality because different protocol controllers require different driver logic and configuration parameters. For example, the BIOS boot code includes a driver management module that, based on the controller type data to be initialized, searches the BIOS storage area and loads the matching driver binary code or configuration script.

[0077] In this embodiment, the protocol switching result data reflects the actual state of the multiplexer's physical switch switching, such as which channel is connected and whether the connection is successful. Register configuration and parameter setting are the core steps in initializing the protocol controller. This involves writing specific values ​​to various control registers within the protocol controller to define its operating mode, clock frequency, data transmission rate, interrupt settings, error handling mechanisms, etc. Using the loaded protocol controller driver ensures correct configuration and protocol compatibility because the driver encapsulates all the configuration logic required by the specific protocol controller. For example, the loaded driver contains a series of functions or routines that set the protocol controller's operating parameters based on the protocol switching result data by reading and writing to the protocol controller's memory-mapped registers or I / O ports.

[0078] In this embodiment, verifying the initialization status is a crucial step in ensuring that the protocol controller is correctly configured and ready for communication. This typically involves reading the protocol controller's internal status registers, checking if it is in the expected operating mode, or performing some self-test procedures. Initialization completion status data is then obtained, i.e., a flag or detailed status code indicating successful or failed initialization is generated. This step provides a feedback mechanism so that the BIOS can determine whether the protocol controller has been successfully activated. For example, after completing register configuration, the driver reads some key status registers of the protocol controller. If the values ​​of these registers meet the protocol specification or preset success conditions, initialization success data is generated; otherwise, initialization failure data is generated.

[0079] In this embodiment, the protocol controller initialization process is completed finally based on the initialization completion status data. This is the final confirmation step in the entire initialization process. If the initialization completion status data indicates success, it means that the protocol controller is fully ready and data transmission can begin. If the indication fails, the BIOS can take appropriate error handling measures, such as retrying initialization, switching to a standby configuration, logging the error, and notifying the system. This step marks the completion of the last critical step in the server's high-speed interface protocol adaptive switching, enabling the server to communicate with the interface board using the correct protocol.

[0080] In this embodiment, by determining the protocol type based on the data, the corresponding protocol controller driver is accurately identified and loaded. Furthermore, by combining the protocol switching result data with detailed register configuration and parameter settings for the protocol controller, this application ensures that the protocol controller is fully and correctly initialized. Moreover, by verifying the initialization state, it further ensures that the protocol controller can enter its optimal working state, effectively avoiding communication anomalies or performance bottlenecks caused by improper initialization. This significantly improves the compatibility, stability, and data transmission efficiency of the server's high-speed interface, enabling the server to flexibly and reliably support multiple high-speed interface protocols.

[0081] In the embodiments of this application, the server high-speed interface protocol adaptive switching method solves the configuration errors and inefficiencies caused by manual operation in traditional technologies by automatically reading board identification data, comparing and processing to generate protocol type determination data, controlling physical switch switching and initializing protocol controller. It can realize the automatic identification and switching of server high-speed interface protocols without manual intervention, significantly improving deployment efficiency, system reliability and hardware compatibility.

[0082] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the adaptive switching method of the server high-speed interface protocol of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0083] This application also provides a server high-speed interface protocol adaptive switching system, see reference. Figure 2 The server high-speed interface protocol adaptive switching system includes: a memory 10, a processor 20, and a server high-speed interface protocol adaptive switching program stored on the memory 10 and executable on the processor 20. The server high-speed interface protocol adaptive switching program is configured to implement the steps of the server high-speed interface protocol adaptive switching method.

[0084] The server high-speed interface protocol adaptive switching system provided in this application, employing the server high-speed interface protocol adaptive switching method in the above embodiments, can improve deployment efficiency, system reliability, and hardware compatibility. Compared with the prior art, the beneficial effects of the server high-speed interface protocol adaptive switching system provided in this application are the same as those of the server high-speed interface protocol adaptive switching method provided in the above embodiments, and other technical features of the server high-speed interface protocol adaptive switching system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0085] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0086] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. All equivalent structural transformations made under the technical concept of this application using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the scope of patent protection of this application.

Claims

1. A method for adaptive switching of high-speed interface protocols for servers, characterized in that, The method includes: After the server is powered on, the programmable logic device reads the board identification data from the identification circuit of the interface board connected to the high-speed physical interface of the server. The board identification data is transmitted to the input / output system BIOS. In the BIOS, the board identification data is compared with a pre-stored identifier-protocol mapping table to obtain protocol type determination data. Based on the protocol type, the corresponding switching control command data is generated by the BIOS. The switching control command data is sent to the programmable logic device to control the multiplexer inside the programmable logic device to perform physical switch switching and obtain protocol switching result data; Based on the protocol type determination data and the protocol switching result data, the BIOS performs initialization processing on the corresponding protocol controller to complete the adaptive switching of the server's high-speed interface protocol.

2. The server high-speed interface protocol adaptive switching method as described in claim 1, characterized in that, After the server powers on, the steps for reading board identification data from the identification circuit of the interface board connected to the server's high-speed physical interface via a programmable logic device include: The connection status of the interface board is detected by the programmable logic device to obtain connection status detection data. Based on the connection status detection data, the resistor network status data is read from the identification circuit of the interface board through the programmable logic device; The resistor network status data is converted into a binary encoding format to generate the board identification data.

3. The server high-speed interface protocol adaptive switching method as described in claim 2, characterized in that, The steps of reading resistor network status data from the identification circuit of the interface board using the programmable logic device include: A communication connection is established between the programmable logic device and the identification circuit of the interface board through the communication interface. Based on the communication connection, the state of the resistor divider network in the identification circuit is read through the programmable logic device; Convert the state of the resistor voltage divider network into voltage value data; The voltage value data is mapped into a binary encoding format to generate the resistor network state data.

4. The server high-speed interface protocol adaptive switching method as described in claim 1, characterized in that, The steps in the BIOS to compare the board identification data with a pre-stored identifier-protocol mapping table to obtain protocol type determination data include: The board identification data is transmitted from the programmable logic device to the BIOS via the system management bus; In the BIOS, the received board identification data is matched with the pre-stored board identification data in the identification-protocol mapping table to obtain the matching result data; Based on the matching result data, the corresponding protocol type is determined, and the protocol type determination data is generated.

5. The server high-speed interface protocol adaptive switching method as described in claim 4, characterized in that, The steps in the BIOS to match the received board identification data with the pre-stored board identification data in the identification-protocol mapping table and obtain the matching result data include: Read the identifier-protocol mapping table from the non-volatile memory area of ​​the BIOS to obtain the mapping table data; The board identification data is compared one by one with the pre-stored board identification data in the mapping table data; When the board identification data matches any pre-stored board identification data, a successful match data is generated as the matching result data. When the board identification data is inconsistent with all pre-stored board identification data, matching failure data is generated as the matching result data.

6. The server high-speed interface protocol adaptive switching method as described in claim 1, characterized in that, The steps for determining the data based on the protocol type and generating corresponding switching control command data through the BIOS include: Based on the protocol type determination data, determine the target protocol controller type that needs to be activated, and obtain the target controller type data; Based on the target controller type data, generate signal path configuration parameters corresponding to the target protocol controller; The signal path configuration parameters are encapsulated into a command format that the programmable logic device can recognize, and the switching control instruction data is generated.

7. The server high-speed interface protocol adaptive switching method as described in claim 1, characterized in that, The steps of controlling the multiplexer inside the programmable logic device to perform physical switching and obtaining protocol switching result data include: The switching control command data is sent from the BIOS to the programmable logic device via the system management bus; The switching control instruction data is parsed in the programmable logic device to extract the multiplexer control parameters; Based on the multiplexer control parameters, a switch control signal is sent to the control port of the multiplexer; The switch control signal controls the switch array inside the multiplexer to perform switching operations, connecting the signal channel of the high-speed physical interface to the signal output terminal of the corresponding protocol controller; The connection status of the switched path is detected, and the protocol switching result data is generated.

8. The server high-speed interface protocol adaptive switching method as described in claim 7, characterized in that, The steps of controlling the switching array inside the multiplexer to perform switching operations via the switch control signal include: Based on the multiplexer control parameters, determine the target signal path to be connected and the original signal path to be disconnected. Generate a switch array control signal sequence; According to the timing sequence of the control signal sequence of the switch array, the cross-point switch matrix inside the multiplexer is controlled to establish a new signal connection path; Disconnect the original signal path; Verify the connection status of the new signal connection path and obtain path verification data.

9. The server high-speed interface protocol adaptive switching method as described in claim 1, characterized in that, Based on the protocol type determination data and the protocol switching result data, the steps of initializing the corresponding protocol controller through the BIOS include: Based on the protocol type determination data, determine the type of protocol controller that needs to be initialized, and obtain the controller type data to be initialized; Based on the controller type data to be initialized, the corresponding protocol controller driver is loaded from the BIOS storage area; Based on the protocol switching result data, the loaded protocol controller driver is used to configure the registers and set the parameters of the protocol controller; Verify the initialization status of the protocol controller and obtain the initialization completion status data; Based on the initialization completion status data, the initialization process of the protocol controller is completed.

10. A server high-speed interface protocol adaptive switching system, characterized in that, The server high-speed interface protocol adaptive switching system includes: a memory, a processor, and a server high-speed interface protocol adaptive switching program stored in the memory and executable on the processor, wherein the server high-speed interface protocol adaptive switching program is configured to implement the steps of the server high-speed interface protocol adaptive switching method as described in any one of claims 1 to 9.

Images