Firmware function verification method, device, equipment, storage medium and program product

Abstract

This application discloses a firmware function verification method, apparatus, device, storage medium, and program product, relating to the field of firmware testing technology. The firmware function verification method includes: reading the module capability register of the optical module under test to obtain the claimed support status of the optical module; performing automated testing on the protocol function items of the optical module under test to obtain the actual behavior results of the protocol function items; and comparing the actual behavior results item by item based on the claimed support status to obtain the firmware function verification result. By comparing the claimed support status with the actual behavior results item by item, a step-by-step comparison between "manufacturer claims" and "actual performance" is achieved. The verification results can serve as objective evidence for optical module procurement acceptance, supplier comparison, and fault location. This ensures that verification results from different manufacturers have a unified data format and judgment logic, allowing for convenient inclusion in a database for horizontal comparison and providing data support for multi-manufacturer selection.

Description

Technical Field

[0001] This application relates to the field of firmware testing technology, and in particular to firmware function verification methods, apparatus, devices, storage media, and program products. Background Technology

[0002] With the explosive growth in bandwidth demand from data centers and high-speed networks, pluggable high-speed optical modules such as Quad Small Form-factor Pluggable Double Density (QSFP-DD) and Octal Small Form-factor Pluggable (OSFP) have been widely deployed. The Common Management Interface Specification (CMIS) protocol, as an industry standard, defines the management interface specifications between optical modules and host devices.

[0003] However, significant differences exist in the implementation of the CMIS protocol among different vendors, specifically in terms of function implementation, state machine behavior, and anomaly reporting mechanisms. This leads to frequent interoperability issues in multi-vendor mixed deployment scenarios. Especially in multi-vendor mixed deployment scenarios, current solutions heavily rely on manual testing, which is time-consuming, inconsistent, and makes it difficult to deeply verify and quantitatively evaluate the "true compliance" and "interoperability" of the CMIS protocol firmware functions of multi-vendor optical modules. Summary of the Invention

[0004] The main purpose of this application is to provide a firmware function verification method, apparatus, device, storage medium, and program product, which aims to solve the technical problem that current firmware function verification schemes cannot deeply verify and quantitatively evaluate the "true compliance" and "interoperability" of CMIS protocol firmware functions of optical modules from multiple manufacturers.

[0005] To achieve the above objectives, this application proposes a firmware function verification method, which includes: Read the module capability register of the optical module under test to obtain the claimed support status of the optical module under test; The protocol function items of the optical module under test are automatically tested to obtain the actual behavior results of the protocol function items; The firmware function verification results are obtained by comparing the actual behavior results with the claimed support status item by item.

[0006] In one embodiment, the step of automatically testing the protocol function items of the optical module under test to obtain the actual behavior results of the protocol function items includes: The system sends control commands corresponding to protocol function items to the optical module under test and collects firmware response data of the optical module under test based on the control commands. The firmware response data includes at least one of register status, interrupt pin level, digital diagnostic monitoring value, and multi-function diagnostic monitoring value. The onboard service signal generation and detection unit sends test signals to the service channel of the optical module under test, and determines the underlying hardware behavior of the optical module under test based on the feedback signal of the optical module under test. End-to-end linkage verification is performed based on the control commands, firmware response data, and underlying hardware behavior to obtain the actual behavior results of the protocol function items.

[0007] In one embodiment, the step of reading the module capability register of the optical module under test to obtain the claimed support status of the optical module under test includes: Read the module capability register of the optical module under test to obtain the protocol version and register mapping table followed by the optical module under test; The claimed resolution rules of the optical module under test are determined according to the protocol version; The claim support status of the tested optical module is determined based on the register mapping table and the claim parsing rules.

[0008] In one embodiment, the step of performing end-to-end linkage verification based on the control command, the firmware response data, and the underlying hardware behavior to obtain the actual behavior result of the protocol function item includes: Based on the correlation analysis of the firmware response data, the control commands, and the underlying hardware behavior, the logical consistency of the protocol function items is determined; The protocol compliance of the protocol function item is determined by comparing the firmware response data and the underlying hardware behavior with the protocol specification corresponding to the protocol version. The actual behavioral results of the protocol function items are determined based on the logical consistency and protocol compliance.

[0009] In one embodiment, the actual behavioral outcome includes: valid and invalid; The step of comparing the actual behavior results item by item based on the claimed support status to obtain the firmware function verification result includes: Based on the claimed support status, the functional support status of the tested optical module for the protocol function item is determined, and the functional support status includes: support and no support; If the function support status is "supported" and the actual behavior result is valid, then the firmware function verification result is determined to be consistent. If the function support status is "supported" and the actual behavior result is "invalid", then the firmware function verification result is determined to be a false claim. If the function support status is not supported and the actual behavior result is valid, then the firmware function verification result is determined to be over-implemented. If the function support status is not supported and the actual behavior result is invalid, then the firmware function verification result is determined to be consistent.

[0010] In one embodiment, the method further includes: The firmware function verification results corresponding to the optical modules under test from different manufacturers are stored in a standardized test database; In response to a user's query request, a multi-vendor firmware function comparison report is generated based on the firmware function verification results in the standardized test database.

[0011] Furthermore, to achieve the above objectives, this application also proposes a firmware function verification device, which includes: The data acquisition module is used to read the module capability register of the optical module under test and obtain the claimed support status of the optical module under test. The functional testing module is used to automatically test the protocol function items of the optical module under test and obtain the actual behavior results of the protocol function items. The function verification module is used to compare the actual behavior results item by item based on the claimed support status to obtain the firmware function verification results.

[0012] In addition, to achieve the above objectives, this application also proposes a firmware function verification device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the firmware function verification method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the firmware function verification method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the firmware function verification method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application obtains the claimed support status of the optical module under test by reading its module capability register; it then performs automated testing on the protocol function items of the optical module under test to obtain the actual behavior results of these function items; and finally, it compares the actual behavior results item by item based on the claimed support status to obtain the firmware function verification results. Because the verification system reads the module capability register of the optical module under test, it is plug-and-play and automatically adapts to the individual differences of the optical modules under test, without the need for pre-configuration of fixed test standards. By comparing the claimed support status with the actual behavior results item by item, it achieves a step-by-step comparison between "manufacturer claims" and "actual performance," transforming firmware quality from a vague description into quantifiable indicators. The verification results can serve as objective evidence for optical module procurement acceptance, supplier comparison, and fault location. This ensures that verification results from different manufacturers have a unified data format and judgment logic, allowing for easy inclusion in a database for horizontal comparison and providing data support for multi-manufacturer selection. When a function item is claimed to be supported but is actually invalid, the system automatically marks it as abnormal, helping users quickly identify exaggerated claims by manufacturers or defects in firmware implementation. Attached Figure Description

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

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the firmware function verification method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the firmware function verification method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the firmware function verification method of this application; Figure 4 This is a flowchart illustrating an example implementation scenario of the firmware function verification method of this application. Figure 5 This is a schematic diagram of the module structure of the firmware function verification device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the firmware function verification method in this application embodiment.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is: read the module capability register of the optical module under test to obtain the claimed support status of the optical module under test; perform automated testing on the protocol function items of the optical module under test to obtain the actual behavior results of the protocol function items; and compare the actual behavior results item by item based on the claimed support status to obtain the firmware function verification results.

[0023] This application provides a solution that, by reading the module capability register of the optical module under test (ODT) to obtain its claimed support status, forms a dynamic verification benchmark for each ODT module. This allows the verification method to adapt to ODT modules from different manufacturers and with different protocol versions, eliminating the need to maintain separate test scripts for each version and significantly reducing maintenance costs. Simultaneously, it transforms static register values, which previously required manual review, into verifiable dynamic behavioral expectations, reducing human error. Automated testing is achieved through a three-layer linkage verification mechanism of "control-observation-operation," which not only verifies whether register writes are successful but also confirms whether the write truly drives underlying hardware behavior (e.g., whether the laser is actually turned off or the rate is actually switched). Regardless of whether the module claims support, the same complete functional verification is performed. This allows the detection of the hidden defect of "over-implementation" (not claimed but actually working), which is completely imperceptible in existing solutions. By comparing the measured results with the module's own claims item by item, three types of judgment results are output. Among them, "false claims" indicate functions promised by the manufacturer but not implemented, and "over-implementation" indicates functions not promised by the manufacturer but actually exist. These two types of defects are the root cause of interoperability problems among multiple manufacturers, providing an objective basis for selecting multiple manufacturers.

[0024] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a computer, server, test platform, test system, etc., or an electronic device or virtual device capable of realizing the above functions. The following description uses a firmware function verification device (hereinafter referred to as the verification device) as an example to illustrate this embodiment and the following embodiments.

[0025] Based on this, embodiments of this application provide a firmware function verification method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the firmware function verification method of this application.

[0026] In this embodiment, the firmware function verification method includes steps S10 to S30: Step S10: Read the module capability register of the optical module under test to obtain the claimed support status of the optical module under test.

[0027] It should be noted that the firmware function verification method in this application embodiment can be used in a firmware function verification system.

[0028] In some embodiments of this application, optical modules can be connected via high-speed copper cables. This architecture avoids common-board interference through physical isolation, but it leads to high cost, complex wiring, and difficulty in scaling. Meanwhile, firmware verification only needs to determine if the function is working (e.g., bit error rate degradation, BERT relocking), without requiring high-precision testing.

[0029] In a preferred embodiment of this application, the firmware function verification system highly integrates the core functions of expensive external instruments onto a single board, directly connecting to the optical module via an onboard high-speed differential line. This solves the problem of shared-board interference and significantly reduces costs and deployment complexity, providing end users with a lightweight and efficient automated verification method.

[0030] It should be noted that the aforementioned onboard high-speed differential lines are high-speed differential signal lines directly printed on the board, used to connect the onboard Bit Error Rate Tester (BERT) chip and the service channel (i.e., high-speed electrical interface) of the optical module under test.

[0031] The board in this application embodiment can specifically include: a Microcontroller Unit (MCU), a service verification unit (i.e., a BERT chip), and a communication and power unit. The MCU is directly connected to the optical module management interface and control pins (LPMode / Reset / ModSel) via an Inter-Integrated Circuit (I2C) / General Purpose Input / Output (GPIO) bus to achieve protocol register reading and writing, control command issuance, and real-time status polling. It can perform millisecond-level precise control of the optical module, ensuring reproducible testing processes and comparable results, and can perform stress tests and performance tests that are difficult to achieve manually. The service verification unit is directly connected to the optical module's service channel via an onboard high-speed differential line to generate and analyze PRBS service signals. It retains essential functions for firmware verification, such as PRBS occurrence detection, error rate statistics, and loopback testing, significantly reducing chip cost and design complexity while meeting firmware verification accuracy requirements. Through PCB layered routing layout, the interference problem between high-speed and low-speed signals on the same board is solved, reducing the cost of a single set of equipment from 500,000-800,000 yuan to several thousand yuan. Communication and power supply unit: Establishes high-speed and stable communication with the host computer via USB / Ethernet, provides adjustable regulated power supply in the range of 9V-12V, realizes test command issuance and test data feedback in real time, supports multi-task concurrent execution and batch automated operation, and ensures stable system operation and timely response.

[0032] The test equipment in this application adopts a "protocol-driven dynamic verification benchmark" mechanism. Instead of predefining fixed judgment criteria, it automatically reads the module capability register of the optical module under test before each test and uses it as the verification standard for the module. This allows the verification method to adapt to optical modules under test from different manufacturers and with different protocol versions. It eliminates the need to maintain test scripts separately for each version, greatly reducing maintenance costs.

[0033] It should be noted that in the CMIS protocol, the module capability register is a set of registers used to store the set of functions supported by the hardware and firmware of the optical module under test. Specifically, the module capability register can include a protocol version register and a function claim register. The protocol version register can be used to store version information such as the major version number and minor version number of the CMIS protocol followed by the optical module under test, which is used to inform the host (i.e., the verification device) of the protocol version of the optical module under test, so that the verification device can parse the other registers of the optical module under test according to the corresponding specification of the protocol version. The function claim register can be used to store the claim information of a specific function supported by the optical module under test, which is used to inform the host which optional functions the module hardware or firmware of the optical module under test has.

[0034] Understandably, the claimed support status refers to the binary status related to the functions supported by the optical module under test (DUT), as claimed by the DUT manufacturer. This indicates whether a function is supported or not supported. Examples include: this module supports TxDisable (transmitter shutdown), this module supports PRBS diagnostics, this module supports 100G speeds, this module does not support loopback mode, this module does not support low-power mode, etc. Through the I2C bus, the verification device can read the binary numbers related to the claimed support status stored in the DUT's module capability register and parse them to obtain the list of claimed support statuses.

[0035] In a specific implementation, the verification device in this application embodiment can read the module capability register of the optical module under test to obtain the claimed support status. This claimed support status can be used as a dynamic verification benchmark and compared with the actual behavior results obtained from the test, thereby enabling the identification of false claims and over-realization.

[0036] Step S20: Perform automated testing on the protocol function items of the optical module under test to obtain the actual behavior results of the protocol function items; Step S30: Based on the claimed support status, compare the actual behavior results item by item to obtain the firmware function verification results.

[0037] It should be noted that the aforementioned protocol function items are the function items supported by the optical module under test, which are read from the module capability register of the optical module under test. Each protocol function item can correspond to an independently verifiable firmware behavior or feature, such as I2C communication function, encoding function, module state machine and control function, data path state machine function, digital diagnostic monitoring (DDM) and flag bit function, versatile diagnostic monitoring (VDM) function, loopback function, pseudo-random binary sequence (PRBS) diagnostic function, module firmware management support command data block (CDB) function, etc. The embodiments of this application do not limit this. The aforementioned actual behavioral results refer to the results of whether the protocol function item is truly effective after performing automated testing on the optical module under test to actually execute control operations (such as register writing, pin pull-high / pull-low) and synchronously observe firmware responses (register status, interrupts, DDM / VDM values) and service channel physical signals (bit error rate, signal lockout, etc.). Specifically, it can include two states: effective and invalid.

[0038] Understandably, by comparing the claimed support status and actual behavior results of the tested optical module item by item, it is possible to determine which protocol functions are normally executed and which are false claims or over-implemented. Specifically, the actual behavior results include: valid and invalid; the step of comparing the actual behavior results item by item based on the claimed support status to obtain the firmware function verification result includes: determining the function support status of the tested optical module for the protocol functions based on the claimed support status, where the function support status includes: supported and not supported; if the function support status is supported and the actual behavior result is valid, then the firmware function verification result is determined to be consistent; if the function support status is supported and the actual behavior result is invalid, then the firmware function verification result is determined to be false claim; if the function support status is not supported and the actual behavior result is valid, then the firmware function verification result is determined to be over-implemented; if the function support status is not supported and the actual behavior result is invalid, then the firmware function verification result is determined to be consistent.

[0039] Understandably, false claims refer to protocol functions that the tested optical module claims to support but cannot be implemented in actual testing, while over-implementation refers to protocol functions that the tested optical module claims not to support but can be implemented in actual testing. When the claimed supported behavior and the actual behavior are the same (i.e., supported + effective, or not supported + ineffective), it indicates that the claimed functionality of the tested optical module is consistent with its actual functionality. If the claimed supported behavior and the actual behavior are different, it indicates that the claimed functionality of the tested optical module is inconsistent with its actual functionality, and there is either false claiming or over-implementation.

[0040] This application embodiment obtains the claimed support status of the optical module under test by reading its module capability register; it then performs automated testing on the protocol function items of the optical module under test to obtain the actual behavior results of these protocol function items; and finally, it compares the actual behavior results item by item based on the claimed support status to obtain the firmware function verification results. Because the verification system reads the module capability register of the optical module under test, it is plug-and-play and automatically adapts to the individual differences of the optical modules under test, without the need for pre-configuration of fixed test standards. By comparing the claimed support status with the actual behavior results item by item, it achieves a step-by-step comparison between "manufacturer claims" and "actual performance," transforming firmware quality from a vague description into quantifiable indicators. The verification results can serve as objective evidence for optical module procurement acceptance, supplier comparison, and fault location. This ensures that verification results from different manufacturers have a unified data format and judgment logic, allowing for easy inclusion in a database for horizontal comparison and providing data support for multi-manufacturer selection. When a function item is claimed to be supported but is actually invalid, the system automatically marks it as abnormal, helping users quickly identify exaggerated claims by manufacturers or defects in firmware implementation.

[0041] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating Embodiment 2 of the firmware function verification method of this application.

[0042] like Figure 2 As shown in this embodiment, the step of automatically testing the protocol function items of the optical module under test to obtain the actual behavior results of the protocol function items includes: Step S21: Send control commands corresponding to protocol function items to the optical module under test, and collect firmware response data of the optical module under test based on the control commands. The firmware response data includes at least one of register status, interrupt pin level, digital diagnostic monitoring value, and multi-function diagnostic monitoring value. Step S22: Send a test signal to the service channel of the optical module under test through the onboard service signal generation and detection unit, and determine the underlying hardware behavior of the optical module under test based on the feedback signal of the optical module under test. Step S23: Perform end-to-end linkage verification based on the control command, the firmware response data, and the underlying hardware behavior to obtain the actual behavior result of the protocol function item.

[0043] It should be noted that by issuing control commands corresponding to protocol function items to the optical module under test, the execution of the protocol function items of the optical module under test can be triggered. By collecting the firmware response data corresponding to the execution of the protocol function item by the optical module under test, the internal state of the optical module under test when executing the control command can be determined. In this embodiment, a fully automated testing engine is constructed. Its core is a modular and scalable CMIS protocol compliance test case library. Through the linkage mechanism of control-state observation-business implementation, the authenticity of firmware functions is deeply verified. The system codifies the logic of each firmware function test and encapsulates it into independent executable test case class functions.

[0044] It should be explained that, in this embodiment of the application, before performing automated testing of each protocol function item, the verification device can automatically read the module status register of the optical module under test to ensure that the optical module under test is in the initial state defined by the protocol (ModuleReady, data path Deactivated, no interruption, etc.), ensuring that the starting point of each test is consistent. By executing this precondition, the uncertainty of manual point testing relying on experience judgment is eliminated, and the interference of the state changes of the preceding test items on the subsequent results is also avoided.

[0045] It should be noted that during automated testing, the test equipment in this application embodiment can send control commands to the firmware of the optical module under test via the I2C bus or GPIO pins to trigger the function to be verified. The control precision can reach the microsecond level and can strictly follow the timing specifications required by the CMIS protocol. The specific control layer operations (i.e., operations triggered by control commands) in this application may include, but are not limited to: register write operations, such as single-byte writes to modify control bits and enable bits, continuous writes to configure application parameters and threshold settings, page selection writes to switch module page spaces, and password writes to verify protected register areas; pin control, such as pulling the LPMode pin high / low to trigger low-power mode switching, pulling the Reset pin low to trigger module hardware reset, and pulling the ModSel pin low to enable I2C communication; service signal control, such as starting / stopping the onboard bit error rate meter, setting PRBS code patterns (PRBS7 / 9 / 13 / 15 / 23 / 31, etc.), and configuring loopback modes (Host loopback, Media loopback, system loopback), etc. Furthermore, after the control layer operation, the verification device captures transient anomalies that cannot be detected by manual point testing through a multi-dimensional synchronous observation mechanism, verifies whether the firmware responds in accordance with the protocol specifications, observes and records various actions generated by the module firmware under different operations: such as whether the register write value changes, whether other registers change synchronously, whether the light and signal transmission are affected, whether the module state machine and DataPath state machine remain in a certain state, and other multi-dimensional data references.

[0046] For example, status register monitoring can be implemented: millisecond-level polling to read status registers (such as ModuleState, DataPathState, ConfigStatus, etc.), recording state machine transition paths and timing, and detecting abnormalities such as illegal jumps, jams, and timeouts; flag register monitoring can also be implemented: reading alarm / warning flag registers (such as TxFault, RxLOS, TempAlarm, etc.), verifying the latching and clearing mechanisms of flag bits, and confirming the consistency between flag bits and actual states; interrupt pin monitoring can also be implemented: real-time monitoring of level changes of hardware pins such as IntL, capturing the timing and duration of interrupt signal generation, and verifying the correlation between interrupts and flag registers; DDM real-time value acquisition can also be implemented: continuously reading monitoring values ​​such as temperature, voltage, bias current, and optical power, analyzing the trend and rationality of numerical changes, and verifying monitoring accuracy and update frequency; VDM diagnostic data reading can also be implemented: scanning the VDM descriptor page, identifying valid instances, reading VDM sample values ​​(such as SNR, Pre-FEC BER, laser temperature, etc.), and verifying VDM statistical functions (freeze / thaw mechanism).

[0047] It should be noted that by issuing control commands to the optical module under test (ODT), one or more firmware response data can be collected, such as register status, interrupt pin level, digital diagnostic monitoring value, and multi-function diagnostic monitoring value, after the ODT responds to the control command. In this embodiment, the actual physical characteristics of the high-speed differential signal can be monitored using an onboard bit error rate analyzer (i.e., the service signal generation and detection unit) to verify whether the firmware control truly drives the underlying hardware. Specifically, the service signal generation and detection unit can continuously send test signals to the ODT via the service channel and receive the feedback signals from the optical module. Based on the feedback signals, the underlying hardware behaviors of the ODT, such as signal integrity, bit error rate, bit error rate, signal lock status, and signal loss flag, can be statistically obtained, thereby determining whether the function corresponding to the control command is actually executed in the underlying hardware.

[0048] For example, the verification module can verify whether the current signal integrity can be adjusted based on the returned signal, and verify whether the performance of the optical module under test, such as the bit error rate, is affected under different write values; it can also perform rate switching verification: after application switching, the bit error rate meter confirms whether the actual rate has switched to the target value, and verifies whether there is signal interruption or sudden increase in bit error rate during the rate switching process; it can also perform loopback function verification: in loopback mode, it verifies the consistency between the transmitted data and the received data, and confirms the correctness of the loopback path.

[0049] Understandably, control commands enable the optical module under test (ODT) to execute corresponding protocol functions. Firmware response data characterizes the firmware state changes that occur after the ODT receives and executes the control commands. Underlying hardware behavior characterizes the actual behavior of the underlying hardware after the ODT receives and executes the control commands. By performing end-to-end linkage verification of these three elements, cross-verification of control command execution can be achieved, revealing the true behavioral results of the ODT and avoiding test result distortion caused by false firmware responses and erroneous responses from the underlying hardware.

[0050] In some embodiments of this application, the verification device can perform fusion analysis on data fed back from the control layer (corresponding to control commands) and the observation layer (observing firmware response data and the underlying hardware behavior of the service layer), automatically acquire firmware defects and record them in the log, thereby realizing logical consistency judgment, protocol compliance judgment and automatic defect acquisition. That is, the step of performing end-to-end linkage verification based on the control commands, the firmware response data and the underlying hardware behavior to obtain the actual behavior result of the protocol function item includes: performing correlation analysis based on the firmware response data, the control commands and the underlying hardware behavior to determine the logical consistency of the protocol function item; comparing the firmware response data and the underlying hardware behavior with the protocol specification corresponding to the protocol version to determine the protocol compliance of the protocol function item; and determining the actual behavior result of the protocol function item based on the logical consistency and the protocol compliance.

[0051] It should be noted that the above logical consistency judgment is based on whether the underlying hardware behavior corresponding to the register states, terminal signals, DDM values, and return signals in the firmware data is logically consistent; the above protocol compliance judgment is based on comparing the firmware response data with the protocol specification of the CMIS protocol version of the optical module under test to determine whether it fully complies with the standard; the above automatic defect acquisition means that when an anomaly is detected in a certain protocol function, the verification device can automatically record the on-site situation before and after the problem occurs, including the register states, interrupt signals, operation logs, and error data, and record them in the test log or test report. R&D personnel can directly reproduce the problem by reviewing the test report, without having to rebuild the environment or repeatedly locate the problem, reducing the time to find the cause from days to hours.

[0052] It should be noted that this application uses a three-layer fusion judgment engine to simultaneously collect response data from the observation layer (register status, interrupt signals, DDM / VDM values) and the service layer (bit error rate, optical power, data rate) after the control layer issues instructions. This data is then used for correlation analysis and logical consistency checks to output a fusion judgment conclusion. Only when the control instructions, firmware responses, and hardware behavior are all consistent with the protocol specifications can the function be considered truly effective. Any anomalies in any layer can be detected through cross-verification of the other two layers.

[0053] In some embodiments of this application, the step of reading the module capability register of the optical module under test to obtain the claimed support status of the optical module under test includes: reading the module capability register of the optical module under test to obtain the protocol version and register mapping table followed by the optical module under test; determining the claim resolution rule of the optical module under test according to the protocol version; and determining the claimed support status of the optical module under test according to the register mapping table and the claim resolution rule.

[0054] It should be noted that before the testing of each protocol function item begins, the verification device can first read the module capability register of the optical module under test to prepare for the test, obtain the protocol version of the optical module under test and the manufacturer's claimed support status for each protocol function item of the protocol version in the optical module under test (such as whether TxDisable is supported, which rates are supported, state machine transition time, etc.). By using the claimed support status as the verification benchmark, the contradiction of "fixed standards either missing tests or making misjudgments" caused by a large number of optional functions in the CMIS protocol is resolved. The claimed supported functions need to be verified to be true, and the claimed unsupported functions also need to be detected to see if there is over-implementation, so as to avoid omissions and misjudgments.

[0055] Understandably, by automatically reading the module protocol version register (e.g., Page00h:01h), the current protocol version (CMIS4.0 / 5.0 / 5.1 / 5.2) is identified, and the corresponding register mapping table and judgment rules are loaded. Simultaneously, the claimed information for each functional item of the module is automatically extracted, and a logic of "claim extraction rule - functional verification test case - consistency judgment logic" is established for each functional item. This transforms the claimed support information from static register values ​​into verifiable dynamic behavioral expectations, enabling dynamic verification of different optical modules.

[0056] In some embodiments of this application, when any protocol function item test is completed, operations such as register default value, disabling PRBS, disabling loopback, clearing interrupt flag, and exiting low power mode can be performed on the optical module under test to restore the environment and ensure that the optical module under test is in the initialized state when the next protocol function item test is performed.

[0057] In some implementations that do not abandon the original embodiments, the test template can refer to the standard CMIS 5.0 protocol, outlining multiple test points including nine core functional items such as I2C, Encoding, Module State & Control, Data Path State Machine, DDM & Flag, VDM, Lookback, PRBS Diagnostics, and CDB. The system supports selecting one or more test items for verification as needed. The verification logic for each test item is pre-coded and solidified in the test plan, and runs automatically after being called. The above steps are linked through "control-observation-business" to ensure the authenticity and integrity of each functional logic during testing.

[0058] In some embodiments of this application, the verification device can have a built-in CMIS protocol compliance test case library, which breaks down the protocol into nine major test items and multiple test points, translating changes in the original register values ​​into multiple executable firmware actions, thus establishing a knowledge foundation for automated testing. Each test case is encapsulated as an independent executable class, inheriting a unified base class interface, and supports selecting one or more test items for verification as needed.

[0059] This embodiment of the application issues control commands corresponding to protocol function items to the optical module under test and collects firmware response data of the optical module under test based on the control commands; it sends test signals to the service channel of the optical module under test through the onboard service signal generation detection unit, and determines the underlying hardware behavior of the optical module under test based on the feedback signal of the optical module under test; it performs end-to-end linkage verification based on the control commands, firmware response data, and underlying hardware behavior to obtain the true behavior results of the protocol function items. Since the underlying hardware behavior is obtained by introducing feedback signal monitoring of the service layer, it avoids being deceived by false firmware responses. By constructing a "stimulus-response-physical effect" causal chain, end-to-end closed-loop verification is achieved, which can not only determine the validity of the function, but also accurately locate the defective link when an anomaly occurs (whether it is firmware non-response, response but no hardware drive, or hardware failure), greatly improving debugging efficiency.

[0060] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the first and / or second embodiments described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating Embodiment 3 of the firmware function verification method of this application.

[0061] like Figure 3 As shown in the embodiments of this application, the method further includes: Step S40: Store the firmware function verification results corresponding to the optical modules under test from different manufacturers into a standardized test database; Step S50: In response to the user's query request, generate a multi-vendor firmware function comparison report based on the firmware function verification results in the standardized test database.

[0062] In some embodiments of this application, after testing, the device can be verified to automatically compare the manufacturer's claims with the actual test results to obtain firmware function verification results, and generate corresponding charts and reports. By unifying the data from multiple manufacturers and versions into a unified database and outputting compliance conclusions, objective basis can be provided for multi-manufacturer selection and compatibility assessment.

[0063] It should be noted that the architecture and capacity of the aforementioned standardized test database can be selected according to the needs of actual applications, and this application embodiment does not impose any limitations on this. The verification device can proactively output a multi-vendor firmware function comparison report, or it can output a multi-vendor firmware function comparison report when it receives a user's query request for different tested optical modules. This application embodiment does not impose any limitations on the generation method or output timing of the multi-vendor firmware function comparison report.

[0064] Understandably, the verification equipment described in this application enables all manufacturers to use the same standardized test case library and judgment rules for testing. The results of each test include manufacturer information, firmware version, claimed status of each functional item, actual test results, and a final judgment (consistent / false claims / over-implementation). These results are stored in a database, forming a test data system that can be accumulated over a long period and compared horizontally. The system records the implementation status of each test point against the claimed protocol support, the implementation status of optional functions, the detection status of unclaimed functions (i.e., over-implementation), and the compliance of anomaly handling. Finally, comparative charts or reports are generated, intuitively showing the differences in protocol compliance, functional completeness, and reliability between different manufacturers' firmware. This allows end customers to anticipate interoperability risks before deployment, thus providing objective data support for supplier selection and product acceptance.

[0065] In one implementation of the embodiments of this application, the overall implementation flow of the firmware function verification method of this application can be as follows: Figure 4 As shown, Figure 4 This is a flowchart illustrating an example implementation scenario of the firmware function verification method of this application.

[0066] Reference Figure 4 Before starting the test, this application embodiment can perform claim resolution on the device under test: obtain the function support declaration by reading the module capability register, and select the test item to be tested (i.e. the protocol function item of the optical module under test to be tested).

[0067] It should be noted that the verification logic for each protocol function item test requires that the precondition of being in an initialization state be met first. When the precondition is met, control commands can be output to the optical module under test (DUT) to control its actions, and the actions of the DUT can be observed, reading information such as its corresponding register status, interrupt pin level, digital diagnostic monitoring values, and multi-function diagnostic monitoring values, thereby determining the actual behavior of the protocol function item. Upon completion of the test for that protocol function item on the DUT, recovery operations such as resetting registers and disabling PRBS can be performed to initialize the DUT.

[0068] Understandably, when the actual behavior results are obtained from the test, the consistency between the claims and the implementation can be determined based on these results. Specifically, the actual behavior results can be compared with the claimed support status. When the actual behavior results and the claimed support status are consistent (i.e., the actual behavior results are invalid and the claimed support status is not supported, or the actual behavior results are valid and the claimed support status is supported), the test can be considered passed and the corresponding result recorded. When the actual behavior results are invalid but the claimed support status is supported (i.e., claimed support but actually invalid), the test can be considered failed and automatic defect acquisition can be triggered, and the corresponding result recorded. When the actual behavior results are valid but the claimed support status is not supported (i.e., not claimed but actually valid), a test warning can be issued and automatic defect acquisition can be triggered (i.e., information before and after the error is recorded), and the corresponding result recorded.

[0069] It should be understood that by storing the results in a database and generating comparison charts / elevations, it is possible to compare test data of optical modules from multiple manufacturers, thereby providing intuitive assistance for selection.

[0070] This application's embodiments store the firmware function verification results of optical modules under test from different manufacturers into a standardized test database. In response to user query requests, a multi-manufacturer firmware function comparison report is generated based on the firmware function verification results in the standardized test database. By standardizing the storage of multi-manufacturer firmware function verification results and supporting on-demand generation of comparison reports, this application upgrades testing from a "one-time verification tool" to a "data-driven decision-making platform that is accumulative, traceable, and comparable." This fundamentally solves the pain points of "no objective data for comparison and inability to predict interoperability risks" in multi-manufacturer selection, significantly improving the reusability of testing investment and the scientific nature of procurement decisions.

[0071] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the firmware function verification method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0072] This application also provides a firmware function verification device, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the module structure of the firmware function verification device according to an embodiment of this application. The firmware function verification device includes: The data acquisition module 10 is used to read the module capability register of the optical module under test and obtain the claimed support status of the optical module under test. The functional testing module 20 is used to automatically test the protocol function items of the optical module under test and obtain the actual behavior results of the protocol function items. The function verification module 30 is used to compare the actual behavior results item by item based on the claimed support status to obtain the firmware function verification results.

[0073] The firmware function verification device provided in this application, employing the firmware function verification method described in the above embodiments, can solve the technical problem that current firmware function verification schemes cannot deeply verify and quantitatively evaluate the "true compliance" and "interoperability" of CMIS protocol firmware functions of multi-vendor optical modules. Compared with the prior art, the beneficial effects of the firmware function verification device provided in this application are the same as those of the firmware function verification method provided in the above embodiments, and other technical features in the firmware function verification device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0074] This application provides a firmware function verification device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the firmware function verification method in the first embodiment described above.

[0075] The following is for reference. Figure 6 This document illustrates a structural schematic diagram of a firmware function verification device suitable for implementing embodiments of this application. The firmware function verification device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The firmware function verification device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0076] like Figure 6As shown, the firmware function verification device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the firmware function verification device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the firmware function verification device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show firmware function verification devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0077] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0078] The firmware function verification device provided in this application, employing the firmware function verification method described in the above embodiments, can solve the technical problem that current firmware function verification schemes cannot deeply verify and quantitatively evaluate the "true compliance" and "interoperability" of CMIS protocol firmware functions of multi-vendor optical modules. Compared with the prior art, the beneficial effects of the firmware function verification device provided in this application are the same as those of the firmware function verification method provided in the above embodiments, and other technical features in this firmware function verification device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

[0080] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0081] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the firmware function verification method in the above embodiments.

[0082] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0083] The aforementioned computer-readable storage medium may be included in the firmware function verification device; or it may exist independently and not assembled into the firmware function verification device.

[0084] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the firmware function verification device, cause the firmware function verification device to: Read the module capability register of the optical module under test to obtain the claimed support status of the optical module under test; The protocol function items of the optical module under test are automatically tested to obtain the actual behavior results of the protocol function items; The firmware function verification results are obtained by comparing the actual behavior results with the claimed support status item by item.

[0085] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0086] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0087] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0088] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described firmware function verification method. This solves the technical problem that current firmware function verification schemes cannot deeply verify and quantitatively evaluate the "true compliance" and "interoperability" of CMIS protocol firmware functions for multi-vendor optical modules. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the firmware function verification method provided in the above embodiments, and will not be repeated here.

[0089] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the firmware function verification method described above.

[0090] The computer program product provided in this application can solve the technical problem that current firmware function verification schemes cannot deeply verify and quantitatively evaluate the "true compliance" and "interoperability" of CMIS protocol firmware functions of multi-vendor optical modules. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the firmware function verification method provided in the above embodiments, and will not be repeated here.

[0091] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A firmware function verification method, characterized in that, The method includes: Read the module capability register of the optical module under test to obtain the claimed support status of the optical module under test, wherein the claimed support status is the support status of the protocol function items claimed by the optical module under test; The protocol function items of the optical module under test are automatically tested to obtain the actual behavior results of the protocol function items, wherein the actual behavior results are the actual support status of the optical module under test for the protocol function items; Based on the claimed support status, the actual behavior results are compared item by item to obtain the firmware function verification results; The step of automating the testing of the protocol function items of the optical module under test to obtain the actual behavior results of the protocol function items includes: The system sends control commands corresponding to protocol function items to the optical module under test and collects firmware response data of the optical module under test based on the control commands. The firmware response data includes at least one of register status, interrupt pin level, digital diagnostic monitoring value, and multi-function diagnostic monitoring value. The onboard service signal generation and detection unit sends test signals to the service channel of the optical module under test, and determines the underlying hardware behavior of the optical module under test based on the feedback signal of the optical module under test. End-to-end linkage verification is performed based on the control commands, firmware response data, and underlying hardware behavior to obtain the actual behavior results of the protocol function items.

2. The firmware function verification method as described in claim 1, characterized in that, The step of reading the module capability register of the optical module under test to obtain the claimed support status of the optical module under test includes: Read the module capability register of the optical module under test to obtain the protocol version and register mapping table followed by the optical module under test; The claimed resolution rules of the optical module under test are determined according to the protocol version; The claim support status of the tested optical module is determined based on the register mapping table and the claim parsing rules.

3. The firmware function verification method as described in claim 2, characterized in that, The step of performing end-to-end linkage verification based on the control command, the firmware response data, and the underlying hardware behavior to obtain the actual behavior result of the protocol function item includes: Based on the correlation analysis of the firmware response data, the control commands, and the underlying hardware behavior, the logical consistency of the protocol function items is determined; The protocol compliance of the protocol function item is determined by comparing the firmware response data and the underlying hardware behavior with the protocol specification corresponding to the protocol version. The actual behavioral results of the protocol function items are determined based on the logical consistency and protocol compliance.

4. The firmware function verification method as described in claim 1, characterized in that, The actual behavior results include: valid and invalid; the step of comparing the actual behavior results item by item based on the claimed support status to obtain the firmware function verification results includes: Based on the claimed support status, the functional support status of the tested optical module for the protocol function item is determined, and the functional support status includes: support and no support; If the function support status is "supported" and the actual behavior result is valid, then the firmware function verification result is determined to be consistent. If the function support status is "supported" and the actual behavior result is "invalid", then the firmware function verification result is determined to be a false claim. If the function support status is not supported and the actual behavior result is valid, then the firmware function verification result is determined to be over-implemented. If the function support status is not supported and the actual behavior result is invalid, then the firmware function verification result is determined to be consistent.

5. The firmware function verification method as described in claim 1, characterized in that, The method further includes: The firmware function verification results corresponding to the optical modules under test from different manufacturers are stored in a standardized test database; In response to a user's query request, a multi-vendor firmware function comparison report is generated based on the firmware function verification results in the standardized test database.

6. A firmware function verification device, characterized in that, The firmware function verification device includes: The data acquisition module is used to read the module capability register of the optical module under test to obtain the claimed support status of the optical module under test, wherein the claimed support status is the support status of the protocol function items claimed by the optical module under test. The functional testing module is used to automatically test the protocol function items of the optical module under test and obtain the actual behavior results of the protocol function items, wherein the actual behavior results are the actual support status of the optical module under test for the protocol function items. The function verification module is used to compare the actual behavior results item by item based on the claimed support status to obtain the firmware function verification results; The functional testing module is also used to issue control commands corresponding to protocol function items to the optical module under test, and to collect firmware response data of the optical module under test based on the control commands. The firmware response data includes at least one of register status, interrupt pin level, digital diagnostic monitoring value, and multi-function diagnostic monitoring value. Through the onboard service signal generation and detection unit, test signals are sent to the service channel of the optical module under test, and the underlying hardware behavior of the optical module under test is determined based on the feedback signal of the optical module under test. End-to-end linkage verification is performed based on the control commands, the firmware response data, and the underlying hardware behavior to obtain the actual behavior results of the protocol function items.

7. A firmware function verification device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the firmware function verification method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the firmware function verification method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the firmware function verification method as described in any one of claims 1 to 5.

Images