Server hardware control requirement customization method, hardware control unit, and control system

Abstract

The application discloses a server hardware control demand customization method, a hardware control unit and a control system, relates to the technical field of server hardware control, and the server hardware control demand customization method comprises the following steps: obtaining an ith standardized configuration parameter set issued by an upper computer; performing i combined legality verification on the standardized configuration parameter set; in the case that the legality verification is passed, identifying at least one parameter change item of the ith standardized configuration parameter set relative to a previous standardized configuration parameter set; and generating a hardware control signal based on the at least one parameter change item, so as to drive a corresponding hardware execution unit to execute a corresponding control function. In this way, the corresponding standardized configuration parameter set can be matched according to different target application scenarios, illegal configurations can be filtered through the legality verification, hardware configuration updating can be performed only for the parameters that have changed, redundant calculation and hardware operation are reduced, and the adaptation efficiency of scenario switching is improved.

Description

Technical Field

[0001] This application relates to the field of server hardware control technology, and in particular to methods for customizing server hardware control requirements, hardware control units, and control systems. Background Technology

[0002] As data centers continue to increase their demands for server computing power, compatibility, and customization, general-purpose servers and artificial intelligence (AI) servers need to provide customized hardware configurations for different customers and application scenarios, resulting in a significant increase in the frequency of changes in the functional requirements of complex programmable logic devices (CPLDs).

[0003] To meet the hardware control needs of different customers and application scenarios, some technologies adopt a source code modification-based custom development model, modifying the Register Transfer Level (RTL) code and generating custom firmware to meet specific requirements. However, this approach relies heavily on manual development and end-to-end verification, resulting in long adaptation cycles and low development efficiency. Other technologies implement simple parameter configurations for single functions such as fan speed control. While this reduces local code modifications, it only covers scattered, single-point control and cannot truly achieve efficient and secure adaptation across multiple scenarios. Therefore, improving the scenario adaptation efficiency and accuracy of server-level hardware control configuration has become an urgent problem to be solved. Summary of the Invention

[0004] This application provides a method for customizing server hardware control requirements, a hardware control unit, and a control system to at least solve the problems of low scenario adaptation efficiency and poor accuracy of server underlying hardware control configuration in related technologies.

[0005] This application provides a method for customizing server hardware control requirements, including: Obtain the i-th standardized configuration parameter set issued by the host computer, where the i-th standardized configuration parameter set is the standardized configuration parameter set corresponding to the hardware control requirements of the i-th target application scenario, and i is a positive integer greater than or equal to 2; For the i-th standardized configuration parameter set, perform the i-th combinational validity check; If the combinational validity test of the i-th combination passes, identify at least one parameter change item of the i-th standardized configuration parameter set relative to the (i-1)-th standardized configuration parameter set; wherein, the (i-1)-th standardized configuration parameter set is the standardized configuration parameter set previously issued by the host computer before the current issuance of the i-th standardized configuration parameter set; For each parameter change item in at least one parameter change item, generate a hardware control signal respectively; Based on each hardware control signal, the corresponding hardware execution unit is driven to perform the control function corresponding to the hardware control signal.

[0006] This application also provides a device for customizing server hardware control requirements, including: The parameter set acquisition module is used to acquire the i-th standardized configuration parameter set issued by the host computer, where the i-th standardized configuration parameter set is the standardized configuration parameter set corresponding to the hardware control requirements of the i-th target application scenario, and i is a positive integer greater than or equal to 2; The legality verification module is used to perform legality verification on the i-th standardized configuration parameter set for the i-th combination. The change item identification module is used to identify at least one parameter change item of the i-th standardized configuration parameter set relative to the (i-1)-th standardized configuration parameter set, provided that the i-th combinational validity test is passed; wherein, the (i-1)-th standardized configuration parameter set is the standardized configuration parameter set previously issued by the host computer before the current issuance of the i-th standardized configuration parameter set. The signal generation module is used to generate hardware control signals for each parameter change item in at least one parameter change item. The hardware control module is used to drive the corresponding hardware execution unit to perform the control function corresponding to each hardware control signal.

[0007] This application also provides a hardware control unit, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described server hardware control requirement customization methods when executing the computer program.

[0008] This application also provides a control system, including a hardware control unit and at least one hardware execution unit, wherein the hardware control unit and the at least one hardware execution unit are respectively connected; The hardware control unit is used to execute the steps of any of the above-mentioned server hardware control requirement customization methods.

[0009] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described server hardware control requirement customization methods.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described server hardware control requirement customization methods.

[0011] In some embodiments of this application, the technical solution involves obtaining the i-th standardized configuration parameter set corresponding to the i-th target application scenario, performing an i-th combinational validity check on the standardized configuration parameter set, and identifying at least one parameter change item in the i-th standardized configuration parameter set compared to the previous version if the check passes. Hardware control signals are then generated based on each parameter change item to drive the corresponding hardware execution unit to perform the corresponding control function. This allows for matching the corresponding standardized configuration parameter set to different target application scenarios, filtering out illegal configurations through validity checks, and updating the hardware configuration only for the changed parameters, eliminating the need to re-flash the entire configuration set. This reduces redundant computation and hardware operations, improving the adaptation efficiency for scenario switching. Thus, it solves the problems of low scenario adaptation efficiency and poor accuracy in server-level hardware control configuration in some technologies. Attached Figure Description

[0012] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A flowchart illustrating a method for customizing server hardware control requirements provided for some embodiments of this application; Figure 2 This is a diagram of the internal architecture of the hardware control unit provided in this application; Figure 3 A customized overall workflow diagram is provided to meet the server hardware control requirements of this application. Figure 4 Schematic diagram of a server hardware control requirement customization device provided for some embodiments of this application; Figure 5 A schematic diagram of a hardware control unit provided for some embodiments of this application; Figure 6 A schematic diagram of the architecture of the first control system provided in this application; Figure 7 A schematic diagram of the architecture of the second control system provided in this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0015] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0016] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] In related technologies, to address the customized hardware control requirements of data center servers for different application scenarios, two main solutions are often adopted: source code modification-based custom development or single-function parameter configuration. However, these solutions suffer from long adaptation cycles, low development efficiency, and can only control single configuration parameters, failing to achieve efficient configuration across multiple scenarios. Therefore, improving the scenario adaptation efficiency and accuracy of server-level hardware control configuration has become an urgent problem to be solved.

[0018] In view of this, this application provides a method for customizing server hardware control requirements, which can solve the above problems. The method for customizing server hardware control requirements can be applied to a hardware control unit; in this application, the hardware control unit can be a CPLD. (See also...) Figure 1 This is a flowchart illustrating a method for customizing server hardware control requirements, provided in some embodiments of this application. Figure 1 In this context, the method for customizing server hardware control requirements includes the following steps: Step S101: Obtain the i-th standardized configuration parameter set issued by the host computer.

[0019] Specifically, the host computer refers to the server cluster management platform deployed on the data center management side, which is responsible for issuing standardized configuration parameter sets according to business deployment requirements.

[0020] Specifically, a standardized configuration parameter set refers to a set of hardware configuration parameters that follow a unified data format and parameter field division. It can be directly parsed and executed by the hardware control unit without modifying the underlying hardware logic code. A standardized configuration parameter set can completely cover all hardware control-related configuration requirements in a class of application scenarios. The i-th standardized configuration parameter set is the standardized configuration parameter set corresponding to the hardware control requirements of the i-th target application scenario, where i is a positive integer greater than or equal to 2.

[0021] Specifically, the i-th target application scenario refers to the i-th business operation scenario that the server needs to adapt to, such as artificial intelligence model training scenario, general cloud computing scenario, high-density storage scenario and edge low-power scenario. Different scenarios have different hardware control requirements for the server.

[0022] In this embodiment, the hardware control unit reads a standardized set of configuration parameters through a standardized communication interface with external devices, supporting three configuration modes to adapt to all scenarios including development, testing, and mass production. The three configuration modes are: 1) Automatic configuration mode of host computer: This application adopts this mode, in which the customer requirement document is imported into a dedicated requirement configuration host computer. The host computer has a built-in requirement parsing engine that automatically converts the requirement items into a standardized parameter configuration table, which is then sent to the hardware control unit through the Baseboard Management Controller (BMC) via the Inter-Integrated Circuit (I2C) bus. No manual intervention is required throughout the process.

[0023] 2) Manual configuration mode of BMC web interface: Operation and maintenance personnel can visually modify configuration items through the BMC web management interface. After the parameters are modified, they are sent to the hardware control unit in real time. It supports configuration preview and immediate effect, and is adapted for rapid on-site debugging.

[0024] 3) Offline local configuration mode: During the mass production stage, configuration parameters can be written directly through the local debugging interface of the hardware control unit without connecting to the host computer and BMC, which is suitable for large-scale and rapid configuration on the production line.

[0025] Understandably, the current configuration parameters of the hardware control unit can be synchronized to the BMC and the host computer. The configuration process supports two methods: individual parameter configuration and batch parameter distribution. Adjustments can be made for a single parameter field or a single parameter item, or a complete set of standardized configuration parameters can be distributed as a package.

[0026] Step S102: Perform the i-th combinational validity check on the i-th standardized configuration parameter set.

[0027] Specifically, legality verification refers to the verification of hardware executability and operational security of the i-th standardized configuration parameter set before the hardware control unit performs parameter configuration. The legality and security of the configuration are verified from four aspects: timing rules, hardware interface, parameter values, and control logic.

[0028] In this embodiment, the hardware control unit parses the specific configuration parameters of the i-th standardized configuration parameter set and sequentially calls the corresponding verification modules to complete the legality verification. For example, for the i-th standardized configuration parameter set corresponding to the artificial intelligence model training scenario, it verifies whether the power-on sequence in its high-power mode is compliant, whether the high-speed bus pin configuration is conflicting, whether the core power consumption threshold is within the safe range, and whether the fault protection logic is self-consistent. Only after all verifications are passed can the subsequent configuration execution process be entered.

[0029] Step S103: If the combinational validity test of the i-th set passes, identify at least one parameter change item of the i-th standardized configuration parameter set relative to the (i-1)-th standardized configuration parameter set.

[0030] Specifically, the (i-1)th standardized configuration parameter set is the standardized configuration parameter set previously issued by the host computer before the current issuance of the i-th standardized configuration parameter set, corresponding to the hardware control requirements of the previous target application scenario.

[0031] Specifically, a parameter change item refers to a specific configuration parameter whose value differs from that of the i-th standardized configuration parameter set and the (i-1)-th standardized configuration parameter set under the same parameter domain. Each parameter change item corresponds to an independent hardware control configuration.

[0032] In this embodiment, the contents of the (i-1)th standardized configuration parameter set and the ith standardized configuration parameter set are compared, and all configuration parameters with differences are filtered out to form at least one parameter change item.

[0033] Step S104: Generate hardware control signals for each parameter change item in at least one parameter change item.

[0034] Specifically, hardware control signals refer to the configuration instruction signals output by the hardware control unit to the underlying hardware execution units such as the power management module, fan control module, pin multiplexing module, and fault protection module, which can realize the updating and adjustment of hardware configuration.

[0035] In this embodiment, the hardware control unit parses each parameter change item, and each parameter change item generates an independent hardware control signal. The signals are independent of each other and are not related to each other.

[0036] Step S105: Based on each hardware control signal, drive the corresponding hardware execution unit to execute the control function corresponding to the hardware control signal.

[0037] In this embodiment, the hardware control unit outputs the generated hardware control signals to the control register or dedicated control interface of the corresponding hardware module through the corresponding hardware control bus. After receiving the control signals, each hardware module updates its own operating parameters or executes the corresponding logical actions to complete the implementation of the corresponding control function.

[0038] In summary, in the technical solutions of some embodiments of this application, the i-th standardized configuration parameter set corresponding to the i-th target application scenario is obtained. The i-th combinational validity check is performed on this standardized configuration parameter set. If the check passes, at least one parameter change item in the i-th standardized configuration parameter set compared to the previous version is identified. Hardware control signals are generated based on each parameter change item to drive the corresponding hardware execution unit to perform the corresponding control function. In this way, the corresponding standardized configuration parameter set can be matched according to different target application scenarios, illegal configurations can be filtered through validity checks, and hardware configuration updates can be performed only on the changed parameters, without needing to completely re-flash the entire configuration set. This reduces redundant calculations and hardware operations, improving the adaptation efficiency of scenario switching. Thus, the problems of low scenario adaptation efficiency and poor accuracy of server-level hardware control configuration in some technologies can be solved.

[0039] In some embodiments, the validity check of the i-th combination includes multiple validity checks, and the method of this application further includes: Step a1: If any validity check fails in the i-th combination validation, the configuration of the i-th standardized configuration parameter set is determined to be invalid.

[0040] Step a2 directly drives the corresponding hardware to execute the control function of the (i-1)th standardized configuration parameter set.

[0041] In this embodiment, the hardware control unit performs a validity check on each item of the i-th standardized configuration parameter set. Once any item fails the check, the remaining checks are immediately terminated, the configuration is determined to be invalid, and no new hardware control signals are generated. Instead, the hardware modules are directly driven to continue executing all control functions corresponding to the (i-1)-th standardized configuration parameter set, maintaining the current operating state of the server.

[0042] It is understandable that when the hardware control unit receives the standardized configuration parameter set for the first time and the configuration of the standardized configuration parameter set is invalid, the configuration parameters of the default safe standardized configuration parameter set are loaded.

[0043] In the above embodiments, the fallback logic when the legality verification fails is clarified, which makes the configuration processing flow in abnormal scenarios more standardized, maintains the continuity and stability of server business operation, and provides reliable support for improving the security and scenario adaptability of server hardware control configuration.

[0044] In some embodiments, the standardized configuration parameter set includes a power-on timing parameter field, a pin configuration parameter field, a heat dissipation strategy parameter field, an alarm management parameter field, a reset control parameter field, and a security configuration parameter field.

[0045] Specifically, the six parameter fields are stored in the demand parameter register matrix inside the hardware control unit. The demand parameter register matrix is ​​a standardized register array that is readable and writable and non-volatile when power is off. The register address, data width, and value range of each parameter field are all standardized and defined, supporting both individual configuration and batch distribution configuration methods.

[0046] Specifically, the power-on timing parameter field refers to the parameter field that carries configuration parameters such as the enable delay, power-down sequence, timing interlock relationship, power-on timeout threshold, and number of retries for each power rail of the server. It is used to configure the start-up and shutdown timing logic of the power system, adapting to the multi-graphics processor group power-on of artificial intelligence servers and the customized timing scenarios of power rails of general servers, including the enable delay configuration of power rails at all levels such as the central processing unit, graphics processor, memory, and peripherals.

[0047] Specifically, the pin configuration parameter field refers to the parameter field that carries the functional definition, input / output direction, pull-up / pull-down configuration, trigger edge / level type, pin multiplexing lock rules and in-situ detection logic of various hardware interface pins. It is used to configure the functional allocation and electrical characteristics of pins to adapt to customer-customized hardware interfaces and heterogeneous computing module pin adaptation scenarios.

[0048] Specifically, the heat dissipation strategy parameter field refers to the parameter field that carries the fan speed control curve, temperature-speed mapping threshold, sensor weighting coefficient, high temperature frequency reduction trigger threshold, emergency speed control strategy and partitioned heat dissipation logic. It is used to configure the operation strategy of the heat dissipation system and adapt to the customized heat dissipation of high-density artificial intelligence servers and data center environment scenarios.

[0049] Specifically, the alarm threshold parameter field refers to the parameter field that carries various types of fault alarms, including hardware fault types, alarm triggering conditions, alarm output methods, fault isolation strategies, alarm masking rules, and fault retry mechanisms. It is used to configure the triggering and reporting logic of the alarm system and adapt to customers' customized alarm needs and high-availability fault isolation scenarios.

[0050] Specifically, the reset control parameter field refers to the parameter field that carries the reset trigger conditions, reset delay, reset priority and reset linkage logic of each hardware module. It is used to configure the execution logic of fault reset and adapt to the reset of heterogeneous modules of artificial intelligence server and the reset protection scenario of core hardware fault.

[0051] Specifically, the security configuration parameter field refers to the parameter field that carries firmware version compatibility rules, configuration modification permissions, parameter lock passwords, secure boot verification rules, and configuration rollback mechanisms. It is used to configure the triggering and execution of hardware security protection mechanisms and to adapt to configuration protection scenarios for version error prevention in mass production and high security requirements.

[0052] Understandably, all parameter fields support online read / write and power-off storage of configuration parameters. After configuration, there is no need to recompile the hardware control unit firmware; the latest configuration parameters can be loaded directly.

[0053] In this embodiment, the standardized configuration parameter set is divided into six independent parameter domains according to the functional dimension, and each parameter domain corresponds to a type of hardware control function.

[0054] In the above embodiments, a multi-dimensional domain partitioning structure for the standardized configuration parameter set is defined, making the organization of configuration parameters more standardized and providing a structured foundation for the domain-based execution of subsequent legality verification and the incremental identification of parameter changes.

[0055] In some embodiments, step S102, performing the i-th combinational validity check on the i-th standardized configuration parameter set, includes: Step S1021: Perform timing validity verification on the i-th standardized configuration parameter set.

[0056] Step S1022: Perform pin conflict verification for the i-th standardized configuration parameter set.

[0057] Step S1023: Perform threshold security verification on the i-th standardized configuration parameter set.

[0058] Step S1024: Perform a logical consistency check on the i-th standardized configuration parameter set.

[0059] Specifically, timing validity verification is used to verify whether there are conflicts in the power-on / power-off timing of each power rail, whether the delay parameters are within the preset safety threshold range, and whether the timing interlock relationship is reasonable. It can prevent chip damage caused by power-on impact and is a verification step to ensure the orderly start and stop of the power system.

[0060] Specifically, pin conflict verification is used to check whether there are multiplexing conflicts in the pin configuration, whether the function definition matches the hardware schematic, and whether the input / output direction configuration is reasonable. It can avoid pin short circuits or signal errors and is a verification step to ensure normal communication of the hardware interface.

[0061] Specifically, threshold safety verification is used to check whether thresholds such as temperature, voltage, and current are within the safe range allowed by the hardware specifications, and whether the fan speed control curve is smooth. It can prevent the hardware from overheating or being damaged by overcurrent due to threshold exceeding the limit, and is a verification link to ensure the safe operation of hardware.

[0062] Specifically, the logical consistency check is used to verify whether there are closed-loop conflicts in the alarm, reset and fault isolation logic, and whether the configuration parameters are compatible with the firmware version. It can avoid functional deadlock or server unresponsiveness after configuration and is a verification step to ensure logical self-consistency.

[0063] In this embodiment, timing validity verification is first performed on the power system to standardize the power system's operating sequence; then, pin conflict verification is performed on the hardware interface dimension to ensure the connection compatibility of each hardware interface; next, threshold safety verification is performed on the parameter value dimension to limit the safety boundaries of all operating parameters; finally, logic consistency verification is performed on the protection logic dimension to ensure that various fault protection logics operate in coordination.

[0064] Understandably, in this application, verification is automatically triggered during the power-on phase of the hardware control unit and the configuration parameter update phase. If the verification fails, the abnormal configuration is rejected, thus avoiding server hardware damage caused by incorrect configuration at the hardware level. The four types of verification are implemented using pipeline logic and executed sequentially. If the previous verification fails, the subsequent verification is terminated directly, thereby improving verification efficiency. The verification time is ≤10ms.

[0065] In the above embodiments, the four-dimensional sub-item execution logic and verification boundary of the legality verification of the i-th combination are clarified, making the execution process of legality verification more hierarchical and standardized. Illegal configurations are filtered from four levels: timing, interface, parameters, and logic, providing reliable support for improving the accuracy and operational reliability of server hardware control configuration.

[0066] In some embodiments, the timing validity check performed on the i-th standardized configuration parameter set in step S1021 includes: Step b1: For any set of front and rear power rails, based on the power-on timing parameter domain, calculate the sum of the power-on completion time of the front power rail and the preset power-on delay time threshold to obtain the allowed start time of the rear power rail.

[0067] Step b2: Determine whether the power-on start-up time of the corresponding downstream power rail is later than the allowed start-up time.

[0068] Step b3: If the power-on start time of all groups on the downstream power rails is later than the corresponding allowed start time, the timing validity check is deemed to have passed.

[0069] Step b4: If the power-on start time on any set of downstream power rails is not later than the corresponding allowed start time, the timing validity check is deemed to have failed.

[0070] Specifically, front and rear power rails refer to two power links in a server power system that have a power supply dependency relationship. The front power rail provides input power or an enable reference for the rear power rail. For example, the 12V main power rail on the motherboard is the front rail, and the power rails of the central processing unit (CPU) power supply, memory power supply, and other loads are the rear rails. The power-on sequence of the front and rear rails must be followed.

[0071] Specifically, the power-on completion time of the preamplifier power rail refers to the moment when the output voltage of the preamplifier power rail rises to the rated operating voltage range and reaches a stable output state.

[0072] Specifically, the preset power-on delay time threshold is the minimum delay value required for the subsequent power supply to start after the preceding power supply has stabilized. This is used to ensure that the preceding power supply is fully stable before starting the subsequent load, and to avoid power fluctuations impacting the subsequent devices. In this application, it is set to the range of 0 to 20ms.

[0073] Specifically, the allowed start time of the power rail of the downstream stage refers to the earliest time when the power rail of the downstream stage can be powered on. Starting earlier than this time may result in unstable power supply and damage to components.

[0074] Specifically, the power-on startup time of the power rail refers to the time point at which the power rail of the power rail begins to output power, which determines the startup timing of the power supply.

[0075] In this embodiment, firstly, for each pair of dependent power rails, the allowed start time of the downstream power supply is calculated based on the power-on completion time of the upstream power rail and a preset power-on delay time threshold. Then, the power-on start time of the downstream power rail set in the configuration is compared with the allowed start time for each pair. If all dependent upstream and downstream power rail pairs meet the timing rule of the upstream stabilizing first and the downstream starting later, the timing validity check of the entire pair is determined to be passed. If any pair of upstream and downstream power rails has a reversed timing or insufficient delay time, the timing validity check is determined to be failed.

[0076] In this embodiment, the formula for determining whether the power-on start time of the corresponding downstream power rail is later than the allowed start time is shown in expression (1).

[0077] (1) in, Indicates the time it takes for the power rail of the preceding stage to be powered on. This indicates the preset power-on delay time threshold. This indicates the power-on startup time of the subsequent power rail.

[0078] Understandably, the timing validity check covers both power-on timing and power-off timing scenarios. The power-off timing check uses the same logic to verify the timing compliance of the downstream power supply going down first and the upstream power supply going down later.

[0079] In the above embodiments, the execution logic of timing validity verification is clarified, making the power timing verification process more standardized. It standardizes the power-on sequence and delay duration of each power rail from the time dimension, effectively avoiding power surges and device damage caused by disordered power-on timing.

[0080] In some embodiments, step S1022, performing pin conflict verification on the i-th standardized configuration parameter set, includes: Step c1: For any group of pins, based on the pin configuration parameter field, verify whether the function configuration, direction configuration, and hardware connection configuration meet the hardware specifications.

[0081] Step c2: If the functional configuration, orientation configuration, and hardware connection configuration of all pins meet the hardware specifications, the pin conflict check is deemed to have passed.

[0082] Step c3: If the functional configuration, orientation configuration, and hardware connection configuration of any set of pins do not meet the hardware specifications, the pin conflict check is deemed to have failed.

[0083] Specifically, any group of pins refers to a set of pins on a server hardware board that are divided according to their functions, such as power pin group, high-speed bus signal pin group, general control pin group, and clock pin group. Each group of pins corresponds to a specific hardware interconnect link and functional boundary.

[0084] Specifically, function configuration refers to the specific function definition assigned to a single pin, such as configuring a pin as an I2C bus clock pin, a hardware reset pin, or a fan speed detection pin, which determines the pin's business function and signal type.

[0085] Specifically, direction configuration refers to the setting of the input and output transmission direction of the pin, including three modes: input, output, and bidirectional, which are used to standardize the signal transmission direction of the pin.

[0086] Specifically, hardware connection configuration refers to the configuration of the hardware electrical connection attributes corresponding to the pin, including level standard, pull-up / pull-down resistor configuration, impedance matching parameters, and filter circuit parameters, which determine the electrical characteristics and interconnect compatibility of the pin.

[0087] Understandably, based on the function configuration, direction configuration, and hardware connection configuration, it is necessary to verify whether the same physical pin is simultaneously assigned two or more mutually exclusive functions, whether the input / output direction configuration of the pin is consistent with the actual connection in the hardware schematic, and whether the pin function definition matches the interface specification of the external peripheral. Only if all of the above verifications are passed can the pin conflict verification be considered passed.

[0088] In this embodiment, for each group of pins, the configuration information in the pin configuration parameter field is used to verify whether it meets the hardware specifications from three dimensions: functional definition, transmission direction, and electrical connection. If all three configuration dimensions of all pin groups meet the specifications of the corresponding hardware and there are no issues such as functional conflicts, reverse directions, or level incompatibility, the overall pin conflict verification is deemed to have passed. If any configuration dimension of any group of pins does not meet the hardware specifications, such as multiple mutually exclusive functions assigned to the same pin, output pins connected to output pins, or level standards not matching, the pin conflict verification is deemed to have failed.

[0089] In the above embodiments, the execution logic of pin conflict verification is clarified, making the pin configuration verification process more standardized. Pin conflicts are checked from three levels: functional, directional, and electrical. This can effectively avoid hardware failures caused by incorrect pin configuration and provide reliable verification support for ensuring the interconnection compatibility and operational stability of server hardware interfaces.

[0090] In some embodiments, the method of this application further includes: Step d1: If multiple functional configurations are found to correspond to the same group of pins, verify whether the multiple functional configurations are in time-division multiplexing mode.

[0091] Step d2: When multiple functions are configured in time-division multiplexing mode, verify whether the time series intervals corresponding to each function configuration overlap, and verify whether the direction configuration switching timing meets the hardware specifications.

[0092] Step d3: If the time series do not overlap and the direction configuration switching timing meets the hardware specifications, determine that the pin configuration meets the hardware specifications.

[0093] Specifically, time-division multiplexing mode refers to a working mode in which multiple functional configurations are divided according to time and occupy the same group of physical pins in a time-division manner. Only one function is active at any given time. Pin resources are shared and reused through time-slice allocation, which is a compliant implementation method for multi-functional pin configuration.

[0094] Specifically, the time series interval corresponding to each function configuration refers to the effective working time period of each function within a complete multiplexing cycle, which is used to clarify the time window for different functions to occupy pins.

[0095] Specifically, the direction configuration switching timing refers to the time node and transition duration of the input / output transmission direction conversion when the pin switches between different functions.

[0096] In this embodiment, firstly, pin groups with multi-function configurations are identified, and it is first verified whether they adopt time-division multiplexing compliant multiplexing mode. If time-division multiplexing is not adopted, it is directly determined that there is a pin function conflict. If time-division multiplexing mode is adopted, it is further verified from two dimensions: time interval overlap and direction switching timing compliance. When both verifications meet the requirements, it is determined that the multi-function configuration of the pin meets the hardware specification requirements.

[0097] In the above embodiments, conflict verification logic in the pin multi-function multiplexing scenario is added, making the pin conflict verification coverage more comprehensive. It not only supports improving the utilization rate of hardware pin resources through pin time-division multiplexing, but also strictly avoids the risk of multiplexing conflict from the time division and timing switching level.

[0098] In some embodiments, the method of this application further includes: Step e1: If multiple functions are configured in non-time-division multiplexing mode, and / or the time series overlaps, and / or the direction configuration switching timing does not meet the hardware specification requirements, it is determined that the pin configuration does not meet the hardware specification requirements.

[0099] In this embodiment, for scenarios where multiple functions are configured on the same pin, if any of the following abnormal situations occur: non-time division multiplexing mode, time series overlap, or non-compliant direction switching timing, it is directly determined that the pin configuration does not meet the hardware specifications, i.e., the pin conflict verification fails.

[0100] In the above embodiments, the judgment rules and triggering conditions for non-compliant situations in the scenario of multi-functional pin configuration are clarified, making the judgment logic of pin conflict verification more complete and ensuring that all pin configurations with potential conflict risks can be accurately identified.

[0101] In some embodiments, when the same group of physical pins needs to carry multiple functions such as integrated circuit bus communication or fan speed detection, the time slice length and scheduling cycle of each multiplexed function are dynamically divided according to the service priority and response latency requirements of each function, and a time-division multiplexing scheduling table is generated. After the time-division multiplexing scheduling table is generated, a time slot conflict pre-check is first performed to check whether the time sequence intervals of each function overlap and whether the direction switching timing meets the hardware switching latency requirements. After the check passes, the pin function switching is dynamically scheduled according to the scheduling table. At the same time, the time slot ratio of each function is dynamically adjusted according to the changes in service load. High-priority functions can temporarily expand the time slot ratio, and low-priority functions correspondingly shrink the time slot.

[0102] In the above embodiments, priority-based dynamic time slot scheduling maximizes pin resource utilization while ensuring no conflicts, adapting to application scenarios with tight interface resources. The time slot conflict pre-checking mechanism ensures that there is no risk of pin function conflict during dynamic scheduling, balancing pin resource utilization and operational reliability.

[0103] In some embodiments, performing a threshold security check on the i-th standardized configuration parameter set in step S1023 includes: Step f1: For any set of parameters to be verified, based on the i-th standardized configuration parameter set, determine whether the parameter configuration value corresponding to the parameter to be verified is within the interval formed by the preset minimum security threshold and the preset maximum security threshold.

[0104] Step f2: If the parameter configuration values ​​of all groups of parameters to be verified are within the corresponding range, the threshold security verification is deemed to have passed.

[0105] Step f3: If the parameter configuration value of any set of parameters to be verified exceeds the corresponding range, the threshold security verification is deemed to have failed.

[0106] Specifically, the parameter configuration value corresponding to the parameter to be verified refers to the specific operating value set for each group of parameters to be verified in the i-th standardized configuration parameter set. The parameters to be verified include, but are not limited to, voltage, current and temperature.

[0107] Specifically, the preset minimum safety threshold refers to the lower limit of parameter operation set in advance according to the hardware device specifications and reliability requirements. When the parameter value is lower than this threshold, it may cause the device to malfunction. The preset maximum safety threshold refers to the upper limit of parameter operation set in advance according to the hardware rated parameters and safety protection specifications. When the parameter value is higher than this threshold, it may cause safety risks such as overload, overheating or overcurrent, or even cause permanent damage to the hardware device.

[0108] In this embodiment, firstly, for each group of parameters to be verified, the corresponding parameter configuration value is extracted from the i-th standardized configuration parameter set and compared with the preset safety threshold range of that group of parameters to verify whether the value is compliant; if the configuration values ​​of all groups of parameters to be verified fall within their respective corresponding safety ranges and there is no case of parameters exceeding the limit, the threshold safety verification is determined to be passed; if the configuration value of any group of parameters to be verified is lower than the corresponding preset minimum safety threshold or higher than the corresponding preset maximum safety threshold, there is a risk of parameter operation, and the threshold safety verification is determined to be failed.

[0109] In the above embodiments, the execution logic of threshold security verification is clarified, making the parameter security verification process more standardized and effectively avoiding security failures such as hardware overload, overheating and device damage caused by unreasonable parameter configuration. This provides a verification basis for ensuring the safe operation of server hardware and the reliability of configuration execution.

[0110] In some embodiments, the parameter to be verified includes temperature, and the method of this application further includes: Step g1: If any fan failure is detected, calculate the total heat dissipation capacity of the remaining normal fans based on the heat dissipation strategy parameter domain.

[0111] Step g2: Calculate the estimated stable temperature based on the total heat dissipation capacity.

[0112] Step g3: If the estimated stable temperature is within the range formed by the preset minimum safety threshold and the preset maximum safety threshold, the threshold safety check is deemed to have passed, and a fan fault alarm message is generated.

[0113] Step g4: If the estimated stable temperature is not within the range formed by the preset minimum safety threshold and the preset maximum safety threshold, the threshold safety verification is determined to have failed.

[0114] Specifically, total heat dissipation capacity refers to the maximum overall heat dissipation calculated by all normally operating fans at their current configuration speed after excluding the faulty fan, representing the actual upper limit of heat dissipation of the cooling system under fault conditions.

[0115] Specifically, the estimated stable temperature refers to the stable operating temperature of the system when it reaches thermal equilibrium, calculated based on the remaining total heat dissipation capacity and the steady-state operating power consumption of the hardware under the current configuration.

[0116] In this embodiment, the operating status of the cooling fans is first monitored in real time. When any fan malfunctions, the configuration parameters of the cooling strategy parameter field are retrieved to calculate the total cooling capacity that the remaining normal fans can provide. Then, combined with the steady-state power consumption of the hardware under the current configuration, the estimated steady-state temperature that the system can reach under fault conditions is calculated. Finally, the estimated steady-state temperature is compared with the preset temperature safety range. If it falls within the safety range, the threshold safety check is deemed to have passed, and a fan fault alarm is generated and reported simultaneously. If it exceeds the safety range, the threshold safety check is deemed to have failed.

[0117] In the above embodiments, temperature threshold verification logic under abnormal operating conditions of fan failure is added, which makes the scenario adaptability stronger. It not only ensures the hardware temperature safety under fault conditions, but also avoids the problem that the verification is qualified under normal operating conditions but there is a risk of overheating directly triggered by fault conditions.

[0118] In some embodiments, for any set of parameters to be verified, based on the i-th standardized configuration parameter set, it is determined whether the parameter configuration value corresponding to the parameter to be verified is within the range formed by the preset minimum security threshold and the preset maximum security threshold, see expression (2).

[0119] (2) in, This represents the check value of the parameter to be checked, in the range [0,1]. This represents the actual configuration value of the parameter to be verified. This represents the minimum security threshold corresponding to the parameter to be verified. This indicates the maximum safety threshold corresponding to the parameter to be verified.

[0120] In this embodiment, the actual parameter configuration value of the parameter to be verified is first extracted from the i-th standardized configuration parameter set, and the preset minimum security threshold and preset maximum security threshold corresponding to the parameter are retrieved at the same time; then the calculation is completed through the above expression to obtain the normalized verification value of the parameter to be verified; finally, by judging whether the verification value falls within the interval [0,1], it can be determined whether the parameter configuration value is within the preset security interval, where a verification value of 0 corresponds to the parameter just reaching the lower security limit, and a verification value of 1 corresponds to the parameter just reaching the upper security limit.

[0121] In the above embodiments, a normalized calculation method for threshold security verification is clarified, enabling various parameters to be verified with different dimensions and magnitudes to complete compliance verification through a unified formula and standard range. The verification logic is more universal and standardized, effectively improving the execution efficiency and judgment accuracy of threshold security verification.

[0122] In some embodiments, performing a logical consistency check on the i-th standardized configuration parameter set in step S1024 includes: Step h1: For any set of logical verification items, based on the alarm management parameter field, reset control parameter field, and security configuration parameter field, determine whether there is a logical conflict between the alarm logic, reset logic, and fault isolation logic, and determine whether the current running firmware version is within the version compatibility range.

[0123] Step h2: If there are no logical conflicts in all group logical verification items and the current firmware version is within the version compatibility range, the logical consistency verification is deemed to have passed.

[0124] Step h3: If any set of logical verification items has a logical conflict or the current firmware version is not within the version compatibility range, the logical consistency verification is determined to have failed.

[0125] Specifically, logical conflicts between alarm logic, reset logic, and fault isolation logic refer to situations where the triggering conditions, execution order, or scope of action of the three types of protection logic are contradictory or mutually exclusive. For example, after fault isolation is triggered, the alarm is forcibly suppressed, resulting in the inability to report the fault. The triggering priority of the reset logic is higher than that of the fault isolation logic, causing the fault to spread, which may lead to the failure of the protection logic or even the expansion of the fault.

[0126] Specifically, the current firmware version refers to the underlying firmware program version currently running on the server hardware control unit, which is the execution carrier of configuration parameters; the version compatibility range refers to the firmware version range that the i-th standardized configuration parameter set is compatible with. If the range is exceeded, problems such as configuration not being parsed or functions not being supported may occur.

[0127] In this embodiment, for each set of logical verification items, based on the configuration information of the three parameter fields of alarm, reset, and security, the triggering timing, execution order, and scope of action of the three types of protection logic are verified one by one to ensure they are consistent and conflict-free. At the same time, it is verified whether the currently running firmware version falls within the compatible version range of the configuration. When there are no contradictions in the protection logic links of all groups, and the current firmware version is compatible with the set of configuration parameters, the overall logical consistency verification is determined to be successful. When any set of protection logic has a contradiction, or the current firmware version is incompatible with the configuration, there is a risk of configuration execution, and the logical consistency verification is determined to be unsuccessful.

[0128] In the above embodiments, the execution logic of logical consistency verification is clarified, making the coverage of logical verification more comprehensive and the judgment criteria more rigorous. This avoids the risk of logical conflict operation from the perspective of protecting logic, and avoids the compatibility problem of configuration that cannot be parsed from the perspective of firmware adaptation.

[0129] In some embodiments, after driving the corresponding hardware execution unit to execute the control function corresponding to each hardware control signal according to each hardware control signal in step S105, the method further includes: Step j1: Obtain the actual parameter values ​​corresponding to each parameter in the standardized configuration parameter set.

[0130] Step j2: Based on the actual parameter values ​​and the pre-acquired current running firmware version number and server hardware model code, generate the i-th set of actual requirement feature codes, which are used by the baseboard management controller to compare the i-th set of actual requirement feature codes with the pre-stored i-th set of standard requirement feature codes.

[0131] Step j3: Obtain the configuration operation abnormality instruction issued by the baseboard management controller. The configuration operation abnormality instruction is the instruction generated by the baseboard management controller when it determines that the i-th group of actual demand feature codes is inconsistent with the pre-stored i-th group of standard demand feature codes.

[0132] Step j4: According to the configuration, the abnormal instruction drives the corresponding hardware execution unit to execute the control function of the (i-1)th standardized configuration parameter set and reports the abnormal information.

[0133] Specifically, the actual parameter values ​​refer to the real-time operating values ​​of each hardware parameter after the hardware executes the control function of the i-th standardized configuration parameter set. These values ​​include, for example, the actual output voltage of the power rail, the actual speed of the cooling fan, and the actual operating temperature of the processor. These values ​​correspond one-to-one with the configuration values ​​of each parameter in the standardized configuration parameter set, and are used to intuitively reflect the actual implementation effect of the configuration commands. In this application, a 32-bit hash value is generated based on the actual parameter values. When the configuration parameters change, the hash value also changes.

[0134] Specifically, the current firmware version number refers to the version identifier of the firmware program currently running in the underlying hardware control unit of the server. In this application, it can be a 16-bit CPLD firmware version number.

[0135] Specifically, the server hardware model code refers to the unique model identification code of the server hardware platform, which carries model-specific information such as hardware device specifications, interface definitions, electrical characteristics and heat dissipation design. In this application, it can be a 16-bit server hardware model code.

[0136] Specifically, the generated actual requirement feature code or standard requirement feature code is a 64-bit binary code. The generation logic is to calculate a 32-bit hash value for the actual parameter value, concatenate it with a 16-bit hardware control unit firmware version number and a 16-bit server hardware model code, and together form a unique 64-bit requirement feature code.

[0137] Specifically, the i-th group of actual requirement feature codes refers to the unique feature identifier generated by integrating the collected actual parameter values, the current running firmware version number, and the server hardware model code according to the preset encoding rules; the i-th group of standard requirement feature codes refers to the expected standard feature identifier corresponding to the i-th standardized configuration parameter set pre-stored in the BMC before configuration distribution after normal execution, which is generated by the standardized configuration parameter set, the adapted firmware version number, and the corresponding model code according to the same encoding rules.

[0138] Specifically, the configuration operation exception instruction refers to the exception handling instruction issued by the BMC to the hardware control unit when it confirms that the actual operating state does not match the expected standard state after comparing the actual requirement feature code with the standard requirement feature code.

[0139] In this embodiment, after the configuration is completed, the actual parameter values ​​of each hardware parameter are collected in real time. Combined with the current firmware version information and hardware model information, the i-th set of actual requirement feature codes representing the current actual operating status is generated and synchronized to the BMC. The BMC calls the pre-stored i-th set of standard requirement feature codes for consistency comparison. If the two match, it means that the configuration has been successfully implemented and the operating status meets expectations. If the two do not match, a configuration operation exception command is generated and issued. After receiving the exception command, the hardware control unit immediately falls back to the control function corresponding to the (i-1)-th standardized configuration parameter set and completes the reporting of exception information.

[0140] Optionally, each version of the standard requirement feature code and standardized configuration parameter set is stored in the onboard memory according to the configuration version number and the corresponding hardware model code, enabling traceability throughout the entire process of requirements, development, testing, mass production, and operation and maintenance. When the BMC performs a requirement feature code consistency comparison, it can directly retrieve the standard requirement feature code of the corresponding version from the local memory to complete the comparison calculation. When a configuration rollback scenario is triggered, the hardware control unit can also directly read the (i-1)th standardized configuration parameter set from the local memory.

[0141] In the above embodiments, an independent effect verification and anomaly rollback mechanism after configuration execution are added, clarifying the configuration rollback and anomaly reporting logic in abnormal scenarios, so that the entire hardware configuration management process forms a complete closed loop, effectively improving the execution accuracy and operational reliability of server hardware configuration updates.

[0142] In some embodiments, step S104, generating hardware control signals according to each parameter change item in at least one parameter change item, includes: Step S1041: Identify the type corresponding to each parameter change item in at least one parameter change item.

[0143] Step S1042: If the type of the parameter change item is numeric, calculate the change magnitude of each parameter change item.

[0144] Step S1043: Determine whether the change range of each parameter change item exceeds the preset range threshold.

[0145] Step S1044: If the change magnitude of a parameter change item exceeds a preset magnitude threshold, generate multiple sub-hardware control signals for each parameter change item.

[0146] Step S1045: If the change range of the parameter change item does not exceed the preset range threshold, generate hardware control signals according to each parameter change item in at least one parameter change item.

[0147] Specifically, the type of parameter change item refers to the category categorized based on the configuration attributes of the parameter change item, including but not limited to numerical, switch, and logic types. Different types of parameter changes correspond to different hardware control methods. Numerical parameter change items refer to parameter change items whose parameters take numerical values, such as power consumption upper limit, fan speed, power supply delay duration, and temperature alarm threshold, etc. The changes before and after are specific numerical adjustments.

[0148] Specifically, the change range refers to the absolute value of the difference between the configuration value after the change and the configuration value before the change for a numerical parameter. The preset range threshold refers to the maximum single adjustment range limit set in advance according to the hardware device. When the parameter change range exceeds the preset range threshold, a one-time adjustment can easily cause damage to the device. For example, a large single adjustment of the power supply voltage can easily cause transient load shocks.

[0149] Specifically, sub-hardware control signals refer to the multiple control signals generated for each step of the adjustment value when a parameter change of a large value is broken down into multiple steps. Multiple sub-hardware control signals are used to drive the corresponding hardware to execute the corresponding control function step by step.

[0150] In this embodiment, for each parameter change item, its corresponding parameter type is first identified. If it is a numerical parameter change item, its change magnitude relative to the previous configuration parameter is calculated. Then, the calculated change magnitude is compared with a preset magnitude threshold. If the change magnitude exceeds the preset magnitude threshold, the target adjustment amount of the parameter is split into multiple intermediate adjustment amounts, and multiple sub-hardware control signals are generated accordingly to drive the hardware to adjust to the target configuration step by step. If the change magnitude does not exceed the preset magnitude threshold, the corresponding hardware control signal is directly generated to complete the configuration adjustment in one go.

[0151] In the above embodiments, the amplitude verification and control signal generation logic of numerical parameter change items are clarified, so that the hardware control signal generation strategy can be dynamically adapted according to the degree of parameter change, and the operational risks caused by large parameter adjustments are avoided by executing large changes in stages.

[0152] See also Figure 2 , Figure 2 This is a diagram of the internal architecture of the hardware control unit provided in this application. Figure 2In this system, the hardware control unit can be divided into five functional components: the requirement parameter register matrix module, the requirement validity hardware verification module, the requirement configuration interaction module, the function execution kernel module, and the requirement-firmware end-to-end traceability module. Externally, it connects to the left-side BMC via I2C / SPI bus and to the right-side memory via SPI bus. The requirement parameter register matrix module carries six parameter fields; the requirement validity hardware verification module is a hardware-level compliance verification module; the requirement configuration interaction module supports three configuration modes and serves as the interaction hub between the hardware control unit and external storage; the function execution kernel module is the driving unit for configuration execution, and its core logic is fixed, completely decoupled from the requirement parameter register matrix, and does not change with requirement changes. It supports the low-level control of heterogeneous computing power modules such as x86, Advanced RISC Machines (ARM) architecture CPUs, GPUs, neural network processors, and FPGAs; the requirement-firmware end-to-end traceability module is responsible for the end-to-end traceability and effect verification of the configuration.

[0153] See also Figure 3 , Figure 3 A customized overall workflow diagram is provided for the server hardware control requirements provided in this application. Figure 3 In this process, the initial step is to analyze requirements and generate standardized configuration parameter sets. It receives business scenario requirements from the host computer and generates standardized configuration parameter sets based on six parameter domains: power-on timing, pin configuration, heat dissipation strategy, alarm management, reset control, and security configuration. These standardized configuration parameter sets are then distributed to the hardware control unit via out-of-band management. Upon receiving the distributed standardized configuration parameter sets, the system sequentially performs four legality checks: timing validity, pin conflict verification, threshold security verification, and logical consistency verification. The system then branches based on the verification results. If any legality check fails, it jumps directly to the exception rollback branch, terminating the subsequent configuration execution process. If all legality checks pass, the standardized configuration parameter sets are loaded according to parameter domains. Based on the loaded configuration parameters, the corresponding hardware modules are driven to execute corresponding control functions. After configuration execution, an actual requirement feature code is generated. Based on the traceability results of the requirement feature code and hardware operating status feedback, the configuration parameters can be dynamically adjusted and maintained. The adjusted configuration is then fed back to the legality verification stage to complete a new round of compliance verification and execution, achieving continuous adaptation and iterative optimization of the configuration.

[0154] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0155] Corresponding to the method for customizing server hardware control requirements, this application also provides a device for customizing server hardware control requirements. (See also...) Figure 4 This is a schematic diagram of a module for a server hardware control requirement customization device provided in some embodiments of this application. Figure 4 In this context, the customized device for server hardware control requirements includes: The parameter set acquisition module 401 is used to acquire the i-th standardized configuration parameter set issued by the host computer, wherein the i-th standardized configuration parameter set is the standardized configuration parameter set corresponding to the hardware control requirements of the i-th target application scenario, and i is a positive integer greater than or equal to 2.

[0156] The legality verification module 402 is used to perform legality verification on the i-th standardized configuration parameter set for the i-th combination.

[0157] The change item identification module 403 is used to identify at least one parameter change item of the i-th standardized configuration parameter set relative to the (i-1)-th standardized configuration parameter set, provided that the i-th combination validity test is passed; wherein, the (i-1)-th standardized configuration parameter set is the standardized configuration parameter set previously issued by the host computer before the current issuance of the i-th standardized configuration parameter set.

[0158] The signal generation module 404 is used to generate hardware control signals according to each parameter change item in at least one parameter change item.

[0159] The hardware control module 405 is used to drive the corresponding hardware to perform the control function corresponding to each hardware control signal.

[0160] In some embodiments, the legality verification module 402 is further configured to: In the legality check of the i-th combination, if any legality check fails, the configuration of the i-th standardized configuration parameter set is deemed invalid. Then it directly drives the corresponding hardware to execute the control function of the (i-1)th standardized configuration parameter set.

[0161] In some embodiments, the standardized configuration parameter set includes a power-on timing parameter field, a pin configuration parameter field, a heat dissipation strategy parameter field, an alarm management parameter field, a reset control parameter field, and a security configuration parameter field.

[0162] In some embodiments, the legality verification module 402 is specifically used for: Perform timing validity checks on the i-th standardized configuration parameter set; For the i-th standardized configuration parameter set, perform pin conflict verification; Perform threshold security checks on the i-th set of standardized configuration parameters; Perform a logical consistency check on the i-th standardized configuration parameter set.

[0163] In some embodiments, the legality verification module 402 is further configured to: For any set of front and rear power rails, based on the power-on timing parameter domain, calculate the sum of the power-on completion time of the front power rail and the preset power-on delay time threshold to obtain the allowed start time of the rear power rail. Determine whether the power-on start-up time of the corresponding downstream power rail is later than the allowable start-up time; If the power-on start time of all groups on the downstream power rails is later than the corresponding allowed start time, the timing legality check is deemed to have passed. If the power-on start time on any of the downstream power rails is not later than the corresponding allowed start time, the timing validity check is deemed to have failed.

[0164] In some embodiments, the legality verification module 402 is further configured to: For any set of pins, based on the pin configuration parameter field, verify whether the function configuration, direction configuration, and hardware connection configuration meet the hardware specifications. If the functional configuration, orientation configuration and hardware connection configuration of all groups of pins meet the hardware specifications, the pin conflict check is deemed to have passed. If the functional configuration, orientation configuration, and hardware connection configuration of any set of pins do not meet the hardware specifications, the pin conflict check is deemed to have failed.

[0165] In some embodiments, the legality verification module 402 is further configured to: When multiple functional configurations corresponding to the same set of pins are verified, it is verified whether the multiple functional configurations are in time-division multiplexing mode. When multiple functions are configured in time-division multiplexing mode, check whether the time series intervals corresponding to each function configuration overlap, and check whether the direction configuration switching timing meets the hardware specifications. If there is no overlap within the time series interval and the direction configuration switching timing meets the hardware specifications, it is determined that the pin configuration meets the hardware specifications.

[0166] In some embodiments, the legality verification module 402 is further configured to: For any set of parameters to be verified, based on the i-th standardized configuration parameter set, determine whether the parameter configuration value corresponding to the parameter to be verified is within the range formed by the preset minimum security threshold and the preset maximum security threshold; If the parameter configuration values ​​of all parameters to be verified are within the corresponding range, the threshold security verification is deemed to have passed. If the parameter configuration value of any set of parameters to be verified exceeds the corresponding range, the threshold security verification is deemed to have failed.

[0167] In some embodiments, the device further includes a configuration operation anomaly verification module, which is specifically used for: Obtain the actual parameter values ​​corresponding to each parameter in the standardized configuration parameter set; Based on the actual parameter values ​​and the pre-acquired current running firmware version number and server hardware model code, the i-th set of actual requirement feature codes is generated, which is used by the baseboard management controller to compare the i-th set of actual requirement feature codes with the pre-stored i-th set of standard requirement feature codes. Obtain the configuration operation abnormality instruction issued by the baseboard management controller. The configuration operation abnormality instruction is the instruction generated by the baseboard management controller when it determines that the i-th group of actual demand feature codes is inconsistent with the pre-stored i-th group of standard demand feature codes. According to the configuration, the abnormal instruction drives the corresponding hardware to execute the control function of the (i-1)th standardized configuration parameter set and reports the abnormal information.

[0168] In some embodiments, the hardware control module 405 is specifically used for: Identify the type corresponding to each parameter change item in at least one parameter change item; If the type of the parameter change item is numeric, calculate the change magnitude of each parameter change item; Determine whether the change in each parameter exceeds a preset threshold. If the change in a parameter exceeds a preset threshold, multiple sub-hardware control signals are generated for each parameter change. These sub-hardware control signals are used to drive the corresponding hardware to execute the corresponding control function step by step. If the magnitude of the parameter change does not exceed the preset magnitude threshold, a hardware control signal is generated for each parameter change item in at least one parameter change item.

[0169] For a description of the features in the embodiment corresponding to the server hardware control requirement customization device, please refer to the relevant description in the embodiment corresponding to the sample data processing method, which will not be repeated here.

[0170] See also Figure 5 The embodiments of this application also provide a hardware control unit, including a memory 10 and a processor 20, wherein the memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the server hardware control requirement customization method embodiments described above.

[0171] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the server hardware control requirement customization method when running.

[0172] Embodiments of this application also provide a control system, such as Figure 6 As shown, Figure 6 A schematic diagram of the architecture of the control system provided in this application. Figure 6 The device includes a hardware control unit and at least one hardware execution unit, with the hardware control unit connected to at least one of the hardware execution units respectively.

[0173] The hardware control unit can be a CPLD, which can be used to execute the steps of the server hardware control requirement customization method in any of the above embodiments. The hardware control unit can be located on the motherboard; for example, it can be a CPLD that originally performs management operations on the motherboard. Alternatively, it can be a newly added CPLD on the motherboard specifically for performing hardware control requirement customization operations, which avoids affecting the original business of the CPLD.

[0174] The hardware execution unit can be any type of controlled device, such as a power chip, temperature sensor, fan, indicator light, and peripheral interface.

[0175] The hardware control unit is connected to multiple hardware execution units respectively. For example, each hardware execution unit is attached to the hardware control unit through a bidirectional link of control signals and status feedback.

[0176] In the control system of this application's embodiments, the hardware control unit can first obtain a standardized configuration parameter set, then perform a validity check on the standardized configuration parameter set, and then generate hardware control signals according to the parameter change items, and output the hardware control signals to the corresponding hardware execution units to drive the hardware execution units to execute the corresponding control functions. In this way, because the standardized configuration parameter set can adapt to the hardware control requirements of different target application scenarios, the validity check can filter illegal configurations, and the parameter change items can indicate the differences in the configuration that needs to be updated in the hardware execution units, the control configuration of different hardware execution units can be made accurate, avoiding the inefficiency caused by completely re-flashing the entire configuration set.

[0177] In some embodiments, the control system further includes a control distribution unit connected to a hardware control unit and connected to at least one hardware execution unit.

[0178] The control distribution unit can be various signal forwarding and control distribution modules, such as a CPU, used to centrally manage multiple hardware execution units and reduce the direct wiring complexity of the hardware control unit.

[0179] In some embodiments, it can be pre-specified that when the signal transmission distance between the hardware execution unit and the hardware control unit is less than or equal to a preset distance threshold, no control distribution unit is set up, and the hardware execution unit and the hardware control unit are directly connected. When the signal transmission distance is greater than the preset distance threshold, a control distribution unit is set up at the location of the hardware execution unit. In this way, for hardware execution units closer to the hardware control unit, the transmission error of the control signal is less, and in this case, a control distribution unit is not needed. For hardware execution units farther from the hardware control unit, the transmission attenuation and interference of the control signal increase, and in this case, a control distribution unit can be set up to ensure the accuracy of the control signal.

[0180] In some embodiments, the control system further includes a host computer and a baseboard management controller, wherein the host computer is connected to the baseboard management controller via an out-of-band management link; The host computer is used to send a pre-built set of standardized configuration parameters to the baseboard management controller via an out-of-band management link; The baseboard management controller is used to send a standardized set of configuration parameters to the hardware control unit.

[0181] The host computer can be a local debugging terminal or located outside the data center server room, connected to the baseboard management controller via a network. The baseboard management controller can be deployed on the motherboard connected to it and may include a web-based management interface to provide a visual entry point for modifying configuration items.

[0182] In some embodiments, the control system further includes a memory connected to a hardware control unit; The hardware control unit is also used to store a standardized set of configuration parameters in memory, and to store the standard requirement feature code generated during the execution of the server hardware control requirement customization method in memory.

[0183] The memory can be connected to the hardware control unit via a serial peripheral interface bus. In scenarios where the server experiences an abnormal power outage and restart, configuration execution fails and a rollback to the previous version is required, or consistency comparison based on standard requirement feature codes is needed, the standardized configuration parameter sets of each version and the standard requirement feature codes of each version can be stored in the memory to avoid hardware control reliability issues caused by configuration data loss due to power failure or inability to rollback.

[0184] In some embodiments, such as Figure 7The control system shown includes at least one hardware execution unit comprising one or more of a power rail device, pins, a heat dissipation device, an alarm device, and a reset device.

[0185] The heat dissipation device can be a fan. When the hardware control unit identifies a parameter change in the i-th standardized configuration parameter set relative to the (i-1)-th standardized configuration parameter set, each parameter change corresponds to a type of hardware execution unit. After power-on or configuration update, the type of the parameter change can indicate the hardware execution unit whose configuration needs to be updated. For example, if the parameter change belongs to the heat dissipation strategy parameter domain, it corresponds to a heat dissipation device. Taking a heat dissipation device as an example, the configuration parameters of the heat dissipation strategy parameter domain in the parameter change can be identified. Then, based on the fan speed control curve and temperature-speed mapping threshold, the target speed is calculated, a hardware control signal is generated, and the heat dissipation device is driven to operate at the target speed.

[0186] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0187] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the server hardware control requirement customization method.

[0188] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described server hardware control requirement customization method embodiments.

[0189] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0190] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0191] The foregoing has provided a detailed description of a server hardware control requirement customization method, hardware control unit, and control system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for customizing server hardware control requirements, characterized in that, The method is executed by a hardware control unit and includes: Obtain the i-th standardized configuration parameter set issued by the host computer, wherein the i-th standardized configuration parameter set is the standardized configuration parameter set corresponding to the hardware control requirements of the i-th target application scenario, and i is a positive integer greater than or equal to 2; For the i-th standardized configuration parameter set, perform the i-th combinational validity check; If the legality verification of the i-th group passes, identify at least one parameter change item of the i-th standardized configuration parameter set relative to the (i-1)-th standardized configuration parameter set; wherein, the (i-1)-th standardized configuration parameter set is the standardized configuration parameter set previously issued by the host computer before the current issuance of the i-th standardized configuration parameter set; A hardware control signal is generated for each of at least one of the parameter change items; Based on each of the hardware control signals, the corresponding hardware execution unit is driven to perform the control function corresponding to the hardware control signal.

2. The server hardware control requirement customization method according to claim 1, characterized in that, The i-th combination validity check includes multiple validity checks, and the method further includes: In the legality check of the i-th combination, if any legality check fails, the configuration of the standardized configuration parameter set described in the i-th instance is deemed invalid. Then the corresponding hardware is directly driven to execute the control function of the (i-1)th set of standardized configuration parameters.

3. The server hardware control requirement customization method according to claim 1, characterized in that, The standardized configuration parameter set includes a power-on timing parameter field, a pin configuration parameter field, a heat dissipation strategy parameter field, an alarm management parameter field, a reset control parameter field, and a security configuration parameter field.

4. The server hardware control requirement customization method according to claim 1 or 2, characterized in that, The step of performing the i-th combinational validity check on the i-th standardized configuration parameter set includes: For the i-th set of standardized configuration parameters, perform a timing validity check; For the i-th set of standardized configuration parameters, perform pin conflict verification; For the i-th set of standardized configuration parameters, perform a threshold security check; For the i-th set of standardized configuration parameters, perform a logical consistency check.

5. The server hardware control requirement customization method according to claim 4, characterized in that, The step of performing a timing validity check on the i-th standardized configuration parameter set includes: For any set of front and rear power rails, based on the power-on timing parameter domain, calculate the sum of the power-on completion time of the front power rail and the preset power-on delay time threshold to obtain the allowed start time of the rear power rail. Determine whether the power-on start-up time of the corresponding downstream power rail is later than the allowable start-up time; If the power-on start time of all groups of the subsequent power rails is later than the corresponding allowed start time, the timing legality check is deemed to have passed. If the power-on start time on any of the subsequent power rails is not later than the corresponding allowed start time, the timing validity check is deemed to have failed.

6. The server hardware control requirement customization method according to claim 4, characterized in that, The step of performing pin conflict verification on the i-th standardized configuration parameter set includes: For any set of pins, based on the pin configuration parameter field, verify whether the function configuration, direction configuration, and hardware connection configuration meet the hardware specifications. If the functional configuration, orientation configuration, and hardware connection configuration of all group pins meet the hardware specifications, the pin conflict check is deemed to have passed. If the functional configuration, orientation configuration, and hardware connection configuration of any set of pins do not meet the hardware specifications, the pin conflict check is deemed to have failed.

7. The server hardware control requirement customization method according to claim 6, characterized in that, The method further includes: When multiple functional configurations corresponding to the same set of pins are detected, it is verified whether the multiple functional configurations are in time-division multiplexing mode; When the multiple functions are configured in time-division multiplexing mode, check whether the time series intervals corresponding to each function configuration overlap, and check whether the direction configuration switching timing meets the hardware specifications. If there is no overlap within the time series interval and the direction configuration switching timing meets the hardware specifications, it is determined that the pin configuration meets the hardware specifications.

8. The server hardware control requirement customization method according to claim 4, characterized in that, The threshold security check performed on the i-th standardized configuration parameter set includes: For any set of parameters to be verified, based on the i-th set of standardized configuration parameters, determine whether the parameter configuration value corresponding to the parameter to be verified is within the range formed by the preset minimum security threshold and the preset maximum security threshold; If the parameter configuration values ​​of all groups of parameters to be verified are within the corresponding range, the threshold security verification is deemed to have passed. If the parameter configuration value of any set of parameters to be verified exceeds the corresponding range, the threshold security verification is deemed to have failed.

9. The server hardware control requirement customization method according to claim 1, characterized in that, After driving the corresponding hardware execution unit to execute the control function corresponding to each hardware control signal, the method further includes: Obtain the actual parameter values ​​corresponding to each parameter in the standardized configuration parameter set; Based on the actual parameter values ​​and the pre-acquired current running firmware version number and server hardware model code, the i-th set of actual requirement feature codes is generated, which is used by the baseboard management controller to compare the i-th set of actual requirement feature codes with the pre-stored i-th set of standard requirement feature codes. Obtain a configuration operation abnormality instruction issued by the baseboard management controller. The configuration operation abnormality instruction is an instruction generated by the baseboard management controller when it determines that the i-th group of actual demand feature codes and the pre-stored i-th group of standard demand feature codes are inconsistent. According to the configuration, the abnormal operation instruction drives the corresponding hardware execution unit to execute the control function of the (i-1)th set of standardized configuration parameters and report the abnormal information.

10. The server hardware control requirement customization method according to claim 1, characterized in that, The step of generating hardware control signals according to each of at least one of the parameter change items includes: Identify the type corresponding to each of at least one of the parameter change items; If the type corresponding to the parameter change item is numeric, calculate the change magnitude of each parameter change item; Determine whether the change magnitude of each parameter change item exceeds a preset magnitude threshold; If the change magnitude of the parameter change item exceeds the preset magnitude threshold, multiple sub-hardware control signals are generated for each parameter change item; wherein, the multiple sub-hardware control signals are used to drive the corresponding hardware to execute the corresponding control function step by step. If the change magnitude of the parameter change item does not exceed the preset magnitude threshold, a hardware control signal is generated for each of the at least one parameter change item.

11. A hardware control unit, characterized in that, include: Memory, used to store computer programs; A processor, used to implement the steps of the server hardware control requirements customization method as described in any one of claims 1 to 10 when executing the computer program.

12. A control system, characterized in that, It includes a hardware control unit and at least one hardware execution unit, wherein the hardware control unit is connected to at least one of the hardware execution units respectively; The hardware control unit is used to perform the steps of the server hardware control requirement customization method as described in any one of claims 1 to 10.

13. The control system according to claim 12, characterized in that, The control system further includes a control distribution unit, which is connected to the hardware control unit and is also connected to at least one of the hardware execution units.

14. The control system according to claim 12, characterized in that, The control system also includes a host computer and a baseboard management controller, wherein the host computer is connected to the baseboard management controller via an out-of-band management link; The host computer is used to send a pre-built standardized configuration parameter set to the baseboard management controller through the out-of-band management link; The baseboard management controller is used to send the standardized configuration parameter set to the hardware control unit.

15. The control system according to claim 14, characterized in that, The control system also includes a memory, which is connected to the hardware control unit; The hardware control unit is further configured to store the standardized configuration parameter set in the memory, and to store the standard requirement feature code generated during the execution of the server hardware control requirement customization method in the memory.

16. The control system according to claim 12, characterized in that, At least one of the hardware execution units includes one or more of a power rail device, a pin, a heat dissipation device, an alarm device, and a reset device.

Images