Debugging system of optical driving chip

Abstract

The invention discloses a debugging system of an optical driving chip, and relates to the technical field of photoelectricity. The debugging system comprises a front-end module and a rear-end module which are connected with each other, the rear-end module comprises a parameter monitoring unit, and the front-end module comprises a user interface; the parameter monitoring unit is used for receiving debugging monitoring parameters uploaded by a target product; the target product is connected with the debugging system, a plurality of optical driving chips to be debugged and a preset interface protocol are arranged in the target product, and a register in each optical driving chip conforms to an SFF-8472 protocol standard; the user interface is used for displaying the debugging monitoring parameters, the user interface comprises a plurality of operable components, and each operable component is associated with the corresponding unit of the back-end module. Therefore, unified debugging of different types of driving chips is realized, and the debugging efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of optoelectronic technology, and in particular to a debugging system for an optical driver chip. Background Art

[0002] With the development of optical fiber communication technology, the demand for home intelligent network management optical modules is growing. At present, optical modules generally adopt BOB (Board on Board) technology, which integrates optical driver chips and optical components on the same substrate to achieve high integration and high reliability.

[0003] At present, there are various driver chips integrated in optical modem products. Driver chips with different product configurations are equipped with detailed data sheets, which describe in detail the configuration of different driver chip registers. However, the designs of driver chip debugging interfaces provided by different suppliers are different, which leads to a complicated debugging process when debugging the driver chips in the products. The communication methods and interfaces between the host computer used for debugging and the driver chips in the products are diverse and complex, which ultimately leads to low debugging efficiency. Summary of the invention

[0004] The main purpose of this application is to provide a debugging system for an optical driver chip, so as to achieve unified debugging of different types of driver chips and improve debugging efficiency.

[0005] To achieve the above-mentioned object, the present application provides a debugging system for an optical driver chip, comprising a front-end module and a back-end module connected to each other, wherein the back-end module comprises a parameter monitoring unit, and the front-end module comprises a user interface; The parameter monitoring unit is used to receive the debugging monitoring parameters uploaded by the target product; the target product is connected to the debugging system, and the target product has multiple optical driver chips to be debugged and a preset interface protocol built in, and the registers in each of the optical driver chips comply with the SFF-8472 protocol standard; The user interface is used to display the debugging monitoring parameters. The user interface includes a plurality of operable components, and each of the operable components is respectively associated with a corresponding unit of the backend module.

[0006] Optionally, the debugging monitoring parameters include temperature, voltage, bias current, received optical power, and transmitted optical power.

[0007] Optionally, the preset interface protocol is configured in a main chip of the target product; the preset interface protocol includes a single-byte write command, a multi-byte write command, a single-byte read command and a multi-byte read command.

[0008] Optionally, the back-end module also includes an information configuration unit, and one of the operable components in the user interface is associated with the information configuration unit; the information configuration unit is used to receive configuration information, address information, selected preset interface protocol, readable and writable password of the optical drive chip, user name and login password of the target product input by the user through the user interface.

[0009] Optionally, the user interface is also used to display the low-byte register value and the high-byte register value of the optical driver chip.

[0010] Optionally, the back-end module also includes a batch processing unit, and one of the operable components in the user interface is associated with the batch processing unit; the batch processing unit is used to batch export the first relevant information of the debugged optical driver chip in the target product, or batch import the second relevant information of the undebugged optical driver chip in the target product.

[0011] Optionally, the back-end module also includes an alarm setting unit, and one of the operable components in the user interface is associated with the alarm setting unit; the alarm setting unit is used to set the alarm threshold value of the debugging monitoring parameters, and to issue an alarm prompt when any of the debugging monitoring parameters exceeds the corresponding alarm threshold value.

[0012] Optionally, the back-end module also includes a lookup table unit, and one of the operable components in the user interface is associated with the lookup table unit; the lookup table unit is used to obtain the temperature value and DAC value of the optical driver chip, and automatically fit and generate a target fitting line based on the temperature value and the DAC value, and determine the lookup table value based on the target fitting line, and update the lookup table value into the lookup table.

[0013] Optionally, the backend module further includes a checksum calculation unit, and one of the operable components in the user interface is associated with the checksum calculation unit; the checksum calculation unit is used to automatically calculate the checksum.

[0014] Optionally, the back-end module further includes an integrated conversion unit, and one of the operable components in the user interface is associated with the integrated conversion unit; the integrated conversion unit is used to convert the original value of the optical driver chip into a read value.

[0015] The debugging system of the optical driver chip of the present application is designed by analyzing that all types of driver chips are designed according to the SFF-8472 protocol standard, so the structure of the driver chip register has certain commonalities, and then the debugging system of the optical driver chip of the present application is designed; by standardizing the register structure of each driver chip and the standardized preset interface protocol, as well as through the joint action of the front-end module and the back-end module in the debugging system, unified debugging and maintenance of each driver chip is achieved, thereby improving the debugging efficiency of the driver chip. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a debugging system for the optical driver chip of the embodiment of the present application; Figure 2 is a schematic diagram of a user interface of an embodiment of the present application; In the figure, 100, back-end module; 110, parameter monitoring unit; 120, information configuration unit; 130, batch processing unit; 140, alarm setting unit; 150, lookup table unit; 160, checksum calculation unit; 170, integrated conversion unit; 180, diagnosis unit; 200, front-end module; 210, user interface.

[0017] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

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

[0019] With the rapid development of fiber-optic communication technology, the demand for optical modules for home intelligent network management is growing. As the core component in the fiber-optic communication system, the performance and stability of the optical module directly affect the transmission quality of the entire network. At present, the design and manufacture of optical modules generally adopt BOB (Board on Board) technology, which integrates the optical driver chip and the optical component on the same substrate to achieve a high-integration, low-power and high-reliability optical module solution.

[0020] Currently, there are more than 10 different types of BOB driver chips integrated in optical modem products, which cover 1G and 10G non-stacked and symmetrical products.

[0021] Each BOB driver chip solution is equipped with a detailed data sheet that details the register configuration of different driver chips. However, although the functions of these chips are similar, there are significant differences in their communication methods and interface designs with the host computer. Specifically, the host computer interface provided by all chip manufacturers is based on the I2C interface, but the interface design is different, that is, the design of the driver chip debugging interface provided by different suppliers is different, resulting in a complicated debugging process when debugging the driver chip in the optical modem product. The communication methods and interfaces between the host computer used for debugging and the driver chip in the product are diverse and complex, which ultimately leads to low debugging efficiency.

[0022] Based on this, an embodiment of the present application provides a debugging system for an optical driver chip, which can support the debugging of all BOB driver chips, and helps to simplify the debugging process and improve debugging efficiency through a universal user interface.

[0023] Figure 1 It is a debugging system for the optical driver chip of the embodiment of the present application. Figure 1 As shown, the debugging system of the optical driver chip may include a front-end module 200 and a back-end module 100 connected to each other, the back-end module 100 includes a parameter monitoring unit 110 , and the front-end module 200 includes a user interface 210 .

[0024] Among them, the parameter monitoring unit 110 is used to receive the debugging monitoring parameters uploaded by the target product; the target product is connected to the debugging system, and the target product has multiple optical driver chips to be debugged and a preset interface protocol built in, and the registers in each optical driver chip comply with the SFF-8472 protocol standard; the user interface 210 is used to display the debugging monitoring parameters, and the user interface 210 includes multiple operable components, and each operable component is associated with a corresponding unit of the back-end module 100.

[0025] In this embodiment, the debugging system may include hardware such as a server and a user terminal. The server may be used to execute the application corresponding to the backend module 100; the user terminal may be used to execute the application corresponding to the frontend module 200 and display the user interface 210 to the user. The user terminal may include (but not limited to): mobile terminals such as mobile phones, laptops, PADs (tablet computers), etc., and fixed terminals such as digital TVs, desktop computers, etc., and the user terminal is not specifically limited here.

[0026] It is understandable that the register structures of current optical driver chips are common and are all designed in accordance with the SFF-8472 protocol standard. Therefore, the debugging system of the embodiment of the present application can be designed by analyzing the structural commonality of all optical driver chip registers. It should be noted that SFF-8472 is a diagnostic monitoring interface standard for optical transceivers, which defines registers and commands for monitoring and diagnosing the performance parameters of optical modules.

[0027] Specifically, the SFF-8472 protocol standard defines a series of registers that are located within a specific address range of the I2C interface. The registers are used to store various monitoring data of the optical module, such as temperature, voltage, bias current, received optical power, transmitted optical power and other key parameters.

[0028] Because of the structural commonality of all optical driver chip registers, each register is used to store key parameters such as temperature, voltage, bias current, received optical power, and transmitted optical power. Therefore, a parameter monitoring unit 110 is set in the debugging system back-end module 100 of this embodiment. The parameter monitoring unit 110 can uniformly read the debugging monitoring parameters from the optical driver chip registers of the target product; further, the user interface 210 can also display the above-mentioned debugging monitoring parameters for the user, so that the user can more conveniently view these key parameters stored in the registers of each optical driver chip.

[0029] It should be noted that the target product described in this embodiment may be: an optical modem product that establishes a connection with a debugging system. The target product may include multiple optical driver chips to be debugged. These optical driver chips may be optical driver chips provided by different suppliers, and the registers in these optical driver chips all comply with the SFF-8472 protocol standard.

[0030] In addition, a preset interface protocol is built into the target product, and the debugging system can communicate with each optical driver chip through the preset interface protocol to control the registers of all optical driver chips of the target product.

[0031] In this embodiment, the user interface 210 can be used to display multiple operable components and the above-mentioned debugging monitoring parameters. Specifically, the user interface 210 can display the monitoring parameters to the user in a visual form (such as a table, a curve, a dashboard, etc.). The user interface 210 can also provide operable components (such as buttons, sliders, input boxes, etc.), and the user can set register parameters through these components to control the debugging of the optical driver chip.

[0032] Each operable component in the user interface 210 may be associated with a specific unit of the backend module 100. For example, a user may input a debugging monitoring parameter through an input box on the user interface 210, and the backend module 100 will convert the operation into a corresponding register configuration and write it to the optical driver chip through the I2C interface.

[0033] As an example, assuming that a certain type of optical driver chip is used in the target product, the workflow of the debugging system is as follows: First, the debugging system is connected to the target product; the parameter monitoring unit 110 of the debugging system reads the debugging monitoring parameters from the register of the optical driver chip to obtain parameters such as temperature, voltage, bias current, received optical power, and transmitted optical power. The user interface 210 displays the specific values ​​of these control and monitoring parameters through a set of operable components (such as input boxes); the user can adjust the value of the control and monitoring parameters through the user interface 210, and the back-end module 100 converts the operation into a register configuration and writes it into the optical driver chip. After adjustment, the parameter monitoring unit 110 re-reads the register data, and the user interface 210 updates the display results in real time.

[0034] Thus, the debugging system of this embodiment realizes efficient debugging and monitoring of various optical driver chips through the collaborative work of the front-end module 200 and the back-end module 100, combined with the standardized register structure of the SFF-8472 protocol, and displays the key parameters of the optical driver chips in real time, helping R&D personnel to quickly locate problems. In addition, through the operable components of the user interface 210, users can intuitively configure register parameters without manually writing complex register configuration codes. The uniformity, real-time nature and ease of use of the debugging system of this embodiment provide strong support for the development of optical module products, significantly improving R&D efficiency and product quality.

[0035] In some implementations, the debug monitoring parameters include temperature, voltage, bias current, received optical power, and transmitted optical power.

[0036] Specifically, the temperature (Temperature) in the debugging monitoring parameters refers to: monitoring the temperature inside the optical module. By monitoring the temperature inside the optical module, it can be ensured that the optical module works within a safe range. The voltage (Voltage) in the debugging monitoring parameters refers to: monitoring the power supply voltage of the optical module. By monitoring the power supply voltage of the optical module, the power supply stability can be ensured. The laser bias current (LaserBias Current) in the debugging monitoring parameters refers to: monitoring the bias current of the laser. By monitoring the bias current of the laser, it can be ensured that the laser works normally. The received optical power (Receive Power) in the debugging monitoring parameters refers to: monitoring the strength of the received optical signal. By monitoring the strength of the received optical signal, the receiving performance can be evaluated. The transmitted optical power (Transmit Power) in the debugging monitoring parameters refers to: monitoring the strength of the emitted optical signal. By monitoring the strength of the emitted optical signal, the transmitting performance can be evaluated.

[0037] In some implementations, the preset interface protocol is configured in a main chip of the target product; the preset interface protocol includes a single-byte write command, a multi-byte write command, a single-byte read command, and a multi-byte read command.

[0038] It is understandable that usually, debugging of the optical driver chip requires communication connection through the I2C communication protocol. However, when debugging the optical driver chip, the optical driver chip has been integrated into the target product, and different types of optical driver chips use different I2C communication protocols. At this time, the external device does not have the ability to directly access the I2C interface of the optical driver chip, so it is impossible to establish a communication connection with the optical driver chip through the I2C communication protocol. Therefore, this application is designed to define a standardized interface for the main chip of the target product, that is, to configure a standard and unified preset interface protocol (i.e., API interface protocol) in the main chip of the target product, so that the debugging system establishes a communication connection with the optical driver chip through the main chip.

[0039] Specifically, the host computer where the debugging system backend module 100 is located can be connected to the main chip of the target product through the network port, and the host computer sends debugging instructions or debugging monitoring parameters to the main chip; the main chip then establishes a connection with the optical driver chip through the I2C communication protocol, and the main chip can use the preset interface protocol to forward the debugging instructions or debugging monitoring parameters sent by the host computer to the optical driver chip. In this way, the debugging system can be compatible with the I2C communication protocol of all optical driver chips and realize the control of all optical driver chip registers.

[0040] When designing the preset interface protocol of this embodiment, it is considered that in actual applications, there are usually only two types of operations on the optical driver chip, namely, write operations and read operations on registers. Therefore, the preset interface protocol also mainly includes write commands and read commands.

[0041] Specifically, according to the subsequent production efficiency requirements, the read and write operations can be expanded to multi-byte write and multi-byte read, respectively. Therefore, the preset interface protocol includes four commands, namely, a single-byte write command, a multi-byte write command, a single-byte read command, and a multi-byte read command.

[0042] The single-byte write command is used to write one byte of data to the specified register address. For example, the single-byte write command can be: pondebugb<I2C_ADDR> <offset>[VALUE], single-byte write command can read or write 8-bit data, the data location is determined by I2C_ADDR and OFFSET. If the VALUE parameter is specified, it means it is a write command. If it is a read command, the read result is printed to the standard output. If it is a write command, "Successful" or the reason for failure is returned. As an example, using a single-byte command to write: pondebug b 0x50 0x10 0xAA writes the value 0xAA to register 0x10 at address 0x50.

[0043] The single-byte read command is used to read one byte of data from the specified register address. For example, the single-byte read command can be pondebug b<I2C_ADDR> <offset>The single-byte read command can read one byte of data from the specified register address. As an example, pondebug b 0x50 0x10 reads data from register 0x10 at address 0x50.

[0044] The multi-byte write command is used to write multiple bytes of data to consecutive register addresses. For example, the multi-byte write command can be:<I2C_ADDR> <delayms><OFFSET_BEGIN><OFFSET_END><VAL1_VAL2_...VALn>The multi-byte write command can write any number of bytes of data. The total length of the write will not exceed 256. The data position is determined by I2C_ADDR, OFFSET_BEGIN, and OFFSET_END. The delayMS parameter can be ignored. The format of the written data is val1_val2...valn. Each byte of data is represented by a hexadecimal number and linked by "_". If the write is successful, "Successful" is returned, otherwise the reason for failure is returned.

[0045] The multi-byte read command is used to read multiple bytes of data from consecutive register addresses. For example, the multi-byte read command can be:<I2C_ADDR> <delayms><OFFSET_BEGIN><OFFSET_END>The multi-byte read command can read any number of bytes of data. The total length of the read will not exceed 256. The data position is determined by I2C_ADDR, OFFSET_BEGIN, and OFFSET_END. The delayMS parameter can be set to milliseconds.

[0046] When the main chip receives the debugging monitoring parameters sent by the host computer, the main chip can use a multi-byte write command or a single-byte write command to write the debugging monitoring parameters into the register of the corresponding optical driver chip. When the main chip receives a debug monitoring parameter call command sent by the host computer, the main chip can use a multi-byte read command or a single-byte read command to call the debug monitoring parameters from the register of the optical driver chip.

[0047] Therefore, by configuring a standardized API interface protocol, communication control can be unified to support communication control of multiple BOB driver chips without developing a separate communication protocol for each chip. It can also improve production efficiency, support multi-byte read and write operations, reduce the number and time of communications, and improve production efficiency. It can also simplify the debugging process: through standardized command formats, simplify the debugging process and reduce debugging complexity. Enhance compatibility, ensure compatibility between different chips, and reduce the difficulty of system integration.

[0048] In some embodiments, the back-end module 100 further includes an information configuration unit 120, and an operable component in the user interface 210 is associated with the information configuration unit 120. The information configuration unit 120 is used to receive the configuration information of the target product, address information, selected preset interface protocol, readable and writable password of the optical driver chip, user name, and login password input by the user through the user interface 210.

[0049] In this embodiment, the information configuration unit 120 is used to receive the configuration information of the target product, address information, selected preset interface protocol, readable and writable password of the optical driver chip, user name and login password input by the user through the user interface 210. The information configuration unit 120 is associated with the operable components in the user interface 210, and the user can input the relevant configuration information through the interface to achieve the initialization connection and register configuration of the target product.

[0050] Specifically, the IP address of the local network card is used to specify the IPv4 address of the PON optical modem product. For example, the IP address of the PON optical modem product is fixed at 192.168.1.1. The solution selection list is used to select the solution for the main chip of the PON product. There are differences in the interface protocols of different main chips, so expandable interface options need to be provided. The read-write password of the optical driver chip is used to access the EEPROM of the BOB driver chip. The register access of some BOB driver chips requires the input of a read-write password. The username and login password are used to log in to Telnet through the network port.

[0051] Figure 2 Schematic diagram of the user interface of the embodiment of the present application. Figure 2 As shown, the user interface 210 may include operable components corresponding to the information configuration unit 120, such as Figure 2 The operable components corresponding to the information configuration unit 120 may include input boxes for configuration information, address information, selected preset interface protocol, read-write password of the optical drive chip, user name, and login password, so that the user can input such information.

[0052] In addition, the operable components corresponding to the information configuration unit 120 may also include a start button and a disconnect button; wherein the start button is used to initialize the product connection and read all register information of the connected BOB product; and the disconnect button is used to exit the Telnet communication of the network port.

[0053] The workflow of the information configuration unit 120 may be: the user inputs configuration information, specifically, the user inputs the configuration information of the target product through the user interface 210, including the IP address, solution selection, readable and writable password, user name and login password, and logs in to Telnet.

[0054] Furthermore, when the user clicks the "Start Button", the debugging system connects to the target product based on the above information entered by the user and verifies the read-write password of the register. After the debugging system successfully authenticates, it will retrieve various data of the target product (such as debugging monitoring parameters, register values, etc.).

[0055] Thus, the user can intuitively input configuration information through the user interface 210 without manually writing complex configuration codes. The information configuration unit 120 automatically initializes the connection and reads the register information, reducing manual operations and improving debugging efficiency. Through password protection, it is ensured that only authorized users can access and configure the registers of the BOB driver chip. The solution selection list supports multiple main chip solutions to ensure the compatibility and scalability of the system.

[0056] In some implementations, the user interface 210 is further configured to display the low-byte register value and the high-byte register value of the light driving chip.

[0057] Continue to refer Figure 2 , Figure 2 Two information boxes can be displayed on the right, one of which can be used to display the low-byte register value of the optical driver chip (such as 0x00~0x7F hexadecimal address bits), and the other can be used to display the high-byte register value of the optical driver chip (such as operating 0x80~0xFF hexadecimal address bits).

[0058] When the debugging system is successfully authenticated, the debugging system will first read the low-segment byte data (0~127 bytes) of page A0. Page A0 usually contains basic information and status data of the optical module. The low-segment bytes may contain key parameters such as temperature and voltage. Further, the debugging system reads the low-segment byte data (0~127 bytes) of page A2. Page A2 may contain more diagnostic and monitoring data, such as laser bias current, received optical power, etc. Further, the debugging system reads the high-segment byte data (0~255 bytes) of page A0. The high-segment bytes may contain more detailed status information or extended parameters. Finally, the debugging system reads the register data of each table in page A2. These registers may contain detailed diagnostic information, such as historical data, error logs, etc.

[0059] In addition, after the user interface 210 displays the low-byte register value and the high-byte register value of the optical driver chip, the user can also double-click the byte unit on the user interface 210 to implement real-time modification operations on the register. Specifically, according to the SFF-8472 protocol, the low-byte area of ​​the A0 page is mainly used to store information such as the serial number (SN) and product number (PN) of the product. This information is an important identifier of the optical module and is usually used for product tracking and management.

[0060] Through the user interface 210 of the debugging system, R&D personnel can directly view this information after logging in; and can also view the string information displayed in the form of ASCII code in the data of the A0 low byte area through the information box of the user interface 210. R&D personnel can directly modify its value by double-clicking the byte in the information box. After the modification, the new value will take effect immediately and be displayed in the interface. For example, double-click the byte 0x41 and change it to 0x44, then the string display will change from "ABC" to "DBC". Therefore, through this intuitive operation method, R&D personnel can quickly view and modify register information without going through cumbersome command protocols.

[0061] In some embodiments, the back-end module 100 also includes a batch processing unit 130, and an operable component in the user interface 210 is associated with the batch processing unit 130; the batch processing unit 130 is used to batch export the first relevant information of the debugged optical driver chip in the target product, or batch import the second relevant information of the undebugged optical driver chip in the target product.

[0062] The batch processing unit 130 is an important component of the back-end module 100, and is used to realize batch export and import of the first relevant information of the optical driver chip in the target product. Specifically, the batch export can export all the register information of the debugged optical driver chip, and the export can be a text file in txt format, which contains the first relevant information, and the first relevant information can be the corresponding relationship between the offset and the register value.

[0063] Batch import can import the second related information of the register of the undebugged optical driver chip from the text file to quickly configure the register. The user interface 210 can also display the imported second related information, which can include the offset address and the register value.

[0064] The operation flow of the batch export function can be: the R&D personnel manually debug the register of the optical driver chip through the user interface 210. After the debugging is completed, click the "batch export" button on the user interface 210. The batch processing unit 130 exports the register information as a text file, and the text file includes the corresponding relationship between the offset and the register value. The operation flow of the batch import function can be: the R&D personnel click the "tool" button in the menu bar of the user interface 210, select the "batch write" option; the batch write interface box pops up, clicks the "open" button on the user interface 210, selects the text file to be imported in batches, and the batch processing unit 130 reads the text file content. After opening the imported txt format text file, it will be displayed on the user interface 210, so that it is easy to view and verify again. The batch write function can import the register values ​​of each table at one time, saving the time of EVT debugging of the R&D personnel, and the accuracy is higher.

[0065] In some embodiments, the back-end module 100 also includes an alarm setting unit 140, and an operable component in the user interface 210 is associated with the alarm setting unit 140; the alarm setting unit 140 is used to set the alarm threshold value of the debugging monitoring parameters, and to issue an alarm prompt when any debugging monitoring parameter exceeds the corresponding alarm threshold value.

[0066] Specifically, the alarm setting unit 140 is an important part of the backend module 100, which is used to set the alarm threshold value of the debugging monitoring parameters and issue an alarm prompt when any debugging monitoring parameter exceeds the corresponding alarm threshold value. The main debugging monitoring parameters include: temperature, voltage, bias current, transmitting power and receiving power. The alarm setting unit 140 supports high control alarms and low control alarms. The user can intuitively set the alarm threshold value through the user interface 210 without manually converting the specific value into a register configuration.

[0067] For example, the alarm threshold can be set in the following manner: the developer selects the "alarm setting" option in the menu toolbar of the user interface 210; the alarm setting interface box pops up to display the current value of each debugging monitoring parameter and the corresponding alarm threshold value. The developer can set the high control alarm threshold value and the low control alarm threshold value of each parameter. After the setting is completed, click the "Save" button, and the alarm setting unit 140 saves the threshold value and applies it to the debugging system. When any debugging monitoring parameter exceeds the set alarm threshold value, the debugging system will issue an alarm prompt, such as displaying an alarm message in the user interface 210 or issuing a sound prompt.

[0068] As an example, assuming that a certain type of optical driver chip is used in the target product, the high control alarm threshold of the temperature is set to 85°C, and the low control alarm threshold is set to -10°C; the high control alarm threshold of the voltage is set to 3.6V, and the low control alarm threshold is set to 3.0V; the high control alarm threshold of the bias current is set to 100mA, and the low control alarm threshold is set to 10mA; the high control alarm threshold of the transmitting power is set to 5dBm, and the low control alarm threshold is set to -10dBm; the high control alarm threshold of the receiving power is set to 0dBm, and the low control alarm threshold is set to -30dBm.

[0069] The debugging system monitors the values ​​of various debugging monitoring parameters in real time. If the temperature exceeds 85°C or is lower than -10°C, the system will issue an alarm. If the voltage exceeds 3.6V or is lower than 3.0V, the system will issue an alarm. If the bias current exceeds 100mA or is lower than 10mA, the system will issue an alarm. If the transmitting power exceeds 5dBm or is lower than -10dBm, the system will issue an alarm. If the receiving power exceeds 0dBm or is lower than -30dBm, the system will issue an alarm.

[0070] Thus, through the alarm setting unit 140, the values ​​of various monitoring parameters can be monitored in real time to ensure that the optical driver chip works within a safe range. When the monitoring parameter exceeds the alarm threshold value, the system will immediately issue an alarm prompt to help R&D personnel quickly locate the problem. The user can intuitively set the alarm threshold value through the user interface 210 without manually converting the specific value into a register configuration, which simplifies the operation process. And by setting high control alarms and low control alarms, it is ensured that the optical driver chip works within a safe range to avoid damage caused by abnormal parameters.

[0071] In some embodiments, the back-end module 100 also includes a lookup table unit 150, and an operable component in the user interface 210 is associated with the lookup table unit 150; the lookup table unit 150 is used to obtain the temperature value and DAC value of the optical driver chip, and automatically fit the target fitting line based on the temperature value and DAC value, and determine the lookup table value based on the target fitting line, and update the lookup table value into the lookup table.

[0072] Specifically, the lookup table unit 150 is used to obtain the temperature value and DAC value of the light driver chip, and automatically fit and generate a target fitting line based on these values. According to the target fitting line, the lookup table unit 150 determines the lookup table value and updates these values ​​to the lookup table. The lookup table unit 150 supports two fitting modes: one is linear fitting, that is, generating a straight line fitting based on two coordinate points; the other is curve fitting, that is, generating a curve fitting based on multiple coordinate points.

[0073] If it is a linear fit, the developer selects a linear fit mode in the user interface 210. Two coordinate points (temp1, dac1) and (temp2, dac2) are input, where temp is the temperature and dac is the DAC value. The lookup table unit 150 calculates the lookup table value (i.e., DAC value) by using the linear fit mode for the temperature points from -40°C to 120°C in steps of 3°C, and automatically writes the calculated DAC value into the lookup table.

[0074] If it is curve fitting, the developer selects the curve fitting method in the user interface 210 and inputs multiple coordinate points (temp1, dac1), (temp2, dac2), ..., (tempn, dacn). The lookup table unit 150 calculates the coefficient of the nth order term according to the curve fitting method, and then calculates the lookup table value (i.e., DAC value) for the temperature points from -40°C to 120°C in steps of 3°C, and automatically writes the calculated DAC value into the lookup table.

[0075] Thus, through the lookup table unit 150, a fitting line can be automatically generated according to the temperature value and the DAC value, and the lookup table value can be calculated, reducing the workload of manual calculation. Through linear fitting or curve fitting, the accuracy of the lookup table value is ensured, and the performance of the light drive chip is optimized. The lookup table value can be automatically updated to the lookup table to ensure that the system uses the latest configuration in real time. And the user only needs to input the coordinate point, and the lookup table unit 150 automatically completes the calculation and update, simplifying the operation process.

[0076] In some embodiments, the backend module 100 further includes a checksum calculation unit 160, and an operable component in the user interface 210 is associated with the checksum calculation unit 160; the checksum calculation unit 160 is used to automatically calculate the checksum.

[0077] The checksum calculation unit 160 is used to automatically calculate the checksum. The checksum is a simple method for verifying data integrity and is usually used in communication protocols to ensure that the data has not been tampered with or damaged during transmission. The checksum calculation unit 160 interacts with the user through the operable components in the user interface 210, simplifying the checksum calculation process.

[0078] In some embodiments, the backend module 100 further includes an integrated conversion unit 170, and an operable component in the user interface 210 is associated with the integrated conversion unit 170; the integrated conversion unit 170 is used to convert the original value of the optical driver chip into a read value.

[0079] Specifically, the integrated conversion unit 170 is used to convert the original value of the optical driver chip into an actual read value. The register of the optical driver chip usually stores the original data, which needs to be converted according to the protocol to obtain the actual physical quantity (such as temperature, voltage, optical power, etc.). The integrated conversion unit 170 interacts with the user through the operable components in the user interface 210, simplifying the conversion process of the original value.

[0080] The specific operation process may be as follows: the R&D personnel selects the original value to be converted in the user interface 210. Clicking the "Convert" button, the integrated conversion unit 170 converts the original value into the actual read value according to the predefined protocol or formula. The conversion result is displayed in the user interface 210 for reference and use by the R&D personnel.

[0081] In some embodiments, the debugging system may further include a diagnostic unit 180, which can provide diagnostic commands for detecting the health status and performance of the optical module. The diagnostic function can help identify and eliminate faults and improve the reliability and stability of the system.

[0082] Thus, the debugging system of the optical driver chip of the embodiment of the present application, through the standardized register structure and API interface protocol, the BOB driver chips of different manufacturers can be seamlessly integrated into the same system, improving the compatibility and maintainability of the debugging system, simplifying the system design and maintenance work. Secondly, by supporting multi-byte read and write operations, the number of communications is reduced, the efficiency of data reading and writing is improved, and the production test and debugging process are accelerated. Furthermore, by defining detailed debugging monitoring parameters and alarm mechanisms through the SFF-8472 protocol standard, the abnormal conditions of the optical module can be discovered and processed in time, and the reliability and stability of the system are improved. Finally, through the design of a general user interface 210UI, the debugger can view and operate the register information intuitively and conveniently, improving work efficiency and user experience.

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

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

Claims

1. A debugging system for an optical driver chip, characterized in that: It includes a front-end module and a back-end module connected to each other, wherein the back-end module includes a parameter monitoring unit, and the front-end module includes a user interface; The parameter monitoring unit is used to receive the debugging monitoring parameters uploaded by the target product; the target product is connected to the debugging system, and the target product has multiple optical driver chips to be debugged and a preset interface protocol built in, and the registers in each of the optical driver chips comply with the SFF-8472 protocol standard; The user interface is used to display the debugging monitoring parameters. The user interface includes a plurality of operable components, and each of the operable components is respectively associated with a corresponding unit of the backend module.

2. The debugging system of the optical driver chip according to claim 1, characterized in that: The debugging monitoring parameters include temperature, voltage, bias current, received optical power and transmitted optical power.

3. The debugging system of the optical driver chip according to claim 1, characterized in that: The preset interface protocol is configured in the main chip of the target product; The preset interface protocol includes a single-byte write command, a multi-byte write command, a single-byte read command, and a multi-byte read command.

4. The debugging system of the optical driver chip according to claim 3, characterized in that: The backend module further comprises an information configuration unit, and one of the operable components in the user interface is associated with the information configuration unit; The information configuration unit is used to receive the configuration information of the target product, address information, the selected preset interface protocol, the readable and writable password of the optical drive chip, the user name and the login password input by the user through the user interface.

5. The debugging system of the optical driver chip according to claim 1, characterized in that: The user interface is also used to display the low-byte register value and the high-byte register value of the optical driver chip.

6. The debugging system of the optical driver chip according to claim 1, characterized in that: The backend module further comprises a batch processing unit, and one of the operable components in the user interface is associated with the batch processing unit; The batch processing unit is used to batch export first relevant information of the debugged optical driver chips in the target product, or batch import second relevant information of the undebugged optical driver chips in the target product.

7. The debugging system of the optical driver chip according to claim 1, characterized in that: The backend module further comprises an alarm setting unit, and one of the operable components in the user interface is associated with the alarm setting unit; The alarm setting unit is used to set the alarm threshold value of the debugging monitoring parameter, and to issue an alarm prompt when any of the debugging monitoring parameters exceeds the corresponding alarm threshold value.

8. The debugging system of the optical driver chip according to claim 1, characterized in that: The backend module further comprises a table lookup unit, and one of the operable components in the user interface is associated with the table lookup unit; The lookup table unit is used to obtain the temperature value and DAC value of the optical driver chip, and automatically fit and generate a target fitting line based on the temperature value and the DAC value, and determine the lookup table value based on the target fitting line, and update the lookup table value into the lookup table.

9. The debugging system of the optical driver chip according to claim 1, characterized in that: The backend module further comprises a checksum calculation unit, and one of the operable components in the user interface is associated with the checksum calculation unit; The checksum calculation unit is used for automatically calculating the checksum.

10. The debugging system of the optical driver chip according to claim 1, characterized in that: The backend module further comprises an integrated conversion unit, and one of the operable components in the user interface is associated with the integrated conversion unit; The integrated conversion unit is used to convert the original value of the light driving chip into a read value.

Images