SERDES verification method and device

Abstract

The invention discloses an SERDES verification method and device, and the method comprises the steps: obtaining a protocol type and a configuration mode supported by a to-be-tested SERDES, generating a first compiling simulation script according to the protocol type, and enabling the script to comprise the clock frequency, the data rate, the parameter configuration of a coding mode, the generation rule of simulation excitation, and a result output path; based on the test requirement and the protocol type, a test top layer file and a file list are determined, and the file list comprises paths of the to-be-tested design file and the test excitation file; calling a script, executing first compiling simulation, and generating a waveform file and a log file; switching to a second protocol type, updating the test top layer file and the file list, and generating a second compiling simulation script; executing secondary compiling simulation to generate a waveform file and a log file corresponding to the second protocol; the log file is analyzed, the bit error rate, the function coverage rate and the time sequence violation are counted, and a comprehensive test report is generated. The method can accelerate the verification speed and reduce the development time.

Description

Technical Field

[0001] The present invention relates to the technical field of integrated circuits, and in particular to a SERDES verification method and device. Background Art

[0002] The serializer / deserializer (SERDES) is a mainstream time-division multiplexing (TDM) and point-to-point (P2P) serial communication technology. On the transmitter side, it converts multiple low-speed parallel signals into high-speed serial signals for transmission via optical cables or copper wires. On the receiver side, it converts the high-speed serial signals back into low-speed parallel signals. In a field-programmable logic array (FPGA), a SERDES transceiver (also called an MGT (Multi-Gigabit Transceiver) transceiver) includes high-speed serial-to-parallel conversion circuitry, clock and data recovery circuitry, data encoding and decoding circuitry, clock correction, and channel bonding circuitry, providing the physical layer foundation for various high-speed serial data transmission protocols. The TX and RX sides of an MGT transceiver function independently and are both composed of two sublayers: the Physical Media Attachment (PMA) and the Physical Coding Sublayer (PCS). This circuitry incorporates a variety of usage modes and configuration parameters, requiring adaptation to various high-speed protocols, making verification complex. Summary of the Invention

[0003] In order to solve the problems existing in the prior art, the embodiments of the present application provide a method, apparatus, computing device, computer storage medium and product containing a computer program for SERDES verification, which can speed up verification and reduce development time.

[0004] In the first aspect, an embodiment of the present application provides a SERDES verification method, including: collecting test requirements, obtaining the protocol type and configuration mode supported by the SERDES to be tested, and generating a corresponding first compilation simulation script according to the protocol type, the script containing parameter configurations of clock frequency, data rate, and encoding method, as well as simulation stimulus generation rules and result output paths; based on the test requirements and protocol type, determining the test top-level file and file list, the file list containing the paths of the design file to be tested and the test stimulus file; calling the script, performing the first compilation simulation, generating waveform files and log files, the waveform files recording signal timing changes, and the log files recording compilation errors, timing violations and functional coverage; switching to the second protocol type, updating the test top-level file and file list, and generating a second compilation simulation script; performing a second compilation simulation, generating waveform files and log files corresponding to the second protocol; parsing all log files, counting bit error rate, functional coverage and timing violations, and generating a comprehensive test report.

[0005] In some possible implementations, the protocol type supported by the SERDES to be tested includes at least one of PCIe, Ethernet, and USB, and the configuration mode includes at least one of data transmission rate, number of channels, and encoding method.

[0006] In some possible implementations, the waveform files are stored by protocol type, and the log file contains assertion check results and detailed location information of timing violations.

[0007] In some possible implementations, updating the test top-level file includes dynamically configuring the encoding mode of the physical coding sublayer PCS and the clock recovery parameters of the physical medium adaptation layer PMA.

[0008] In some possible implementations, the generation rules of the simulation stimulus include: automatically generating data packets that comply with specifications according to the protocol type, and supporting the injection of error bits or abnormal signals to verify robustness.

[0009] In some possible implementations, the file list ensures the consistency of the simulation environment through hash verification, and the file version information is recorded before each simulation.

[0010] In some possible implementations, the compiled simulation script switches protocol parameters through conditional compilation instructions, and supports batch calling of multiple scripts to achieve fully automated verification.

[0011] On the second aspect, an embodiment of the present application provides a SERDES verification device, which is deployed in a verification system. The device includes: a compilation and result output module, which is used to compile simulation scripts as operation instructions to drive the simulation process; during the simulation execution, a simulation log file is generated, and the simulation log file is used to record the simulation process information; a simulation waveform file is generated, and the simulation waveform file is used to present signal changes; a file list module to be tested, which is used to clearly list various files required for the compilation simulation according to different test scenarios; a SERDES design file module, which is used to save the SERDES code file to be tested; a test top-level configuration module, which is used to configure the configuration parameters of different high-speed protocols, to cope with the testing of various SERDES usage scenarios, and to achieve comprehensive verification of the SERDES function.

[0012] In a third aspect, an embodiment of the present application provides a computer-readable storage medium comprising computer-readable instructions. When a computer reads and executes the computer-readable instructions, the computer executes the method as described in any one of the first aspects.

[0013] In a fourth aspect, an embodiment of the present application provides a computing device comprising a processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the method as described in any one of the first aspects is executed.

[0014] In a fifth aspect, an embodiment of the present application provides a product comprising a computer program, which, when the computer program product runs on a processor, enables the processor to execute the method as described in any one of the first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0016] Figure 1 This is a schematic diagram of a SERDES architecture provided in an embodiment of the present application;

[0017] Figure 2 This is a schematic diagram of the structure of a verification system provided in an embodiment of the present application;

[0018] Figure 3 1 is a flow chart of a SERDES verification method provided in an embodiment of the present application;

[0019] Figure 4 This is a simulation verification flowchart provided in an embodiment of the present application. DETAILED DESCRIPTION

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0021] The term "and / or" as used herein describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. The symbol " / " as used herein indicates that the related objects are in an "or" relationship, for example, A / B means either A or B.

[0022] The terms "first" and "second" in this specification and claims are used to distinguish different objects rather than to describe a specific order of objects. For example, "first response message" and "second response message" are used to distinguish different response messages rather than to describe a specific order of response messages.

[0023] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0024] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, for example, multiple processing units means two or more processing units, etc.; multiple elements means two or more elements, etc.

[0025] To facilitate understanding of the embodiments of the present application, further explanation will be given below with reference to specific embodiments in conjunction with the accompanying drawings. The embodiments do not constitute a limitation on the embodiments of the present invention.

[0026] First, the technical terms involved in the embodiments of this application are introduced:

[0027] 1. Register-transfer level (RTL) is an abstract model of synchronous digital circuits in digital circuit design. The RTL model is based on the flow of digital signals between logic units such as hardware registers, memories, combinational logic devices, and buses, as well as their logical algebraic operation.

[0028] Next, the technical solutions provided in the embodiments of the present application are introduced.

[0029] SERDES technology has been widely used in modern communications, networking and storage systems. With the popularity of data centers and cloud computing, the demand for high-speed serial interfaces is increasing, so the position of SERDES technology in these fields is becoming more and more important. For example, Figure 1 A SERDES architecture diagram provided by an embodiment of the present application is shown. Figure 1 As shown, the TX and RX sides of a SERDES transceiver function independently and are composed of two sublayers: the Physical Media Adaptation (PMA) and the Physical Coding Sublayer (PCS). The PMA sublayer integrates high-speed serial-to-parallel conversion circuitry, pre-emphasis circuitry, receive equalization circuitry, clock generation circuitry, and clock recovery circuitry. The PCS sublayer integrates 8B / 10B encoding / decoding circuitry, elastic buffering circuitry, channel bonding circuitry, and clock correction circuitry. Because this circuitry includes multiple applicable modes, multiple configuration files are required to adapt to different protocols (such as PCIe and Ethernet) and SERDES configuration modes (such as data rates and encoding methods). During development, developers must write test scripts for each protocol to verify each, making verification cumbersome and error-prone. Furthermore, developers must adjust the top-level test files and file lists, which is time-consuming and prone to configuration omissions.

[0030] In view of this, an embodiment of the present application provides a SERDES verification method, which implements rapid verification of multiple protocols and multiple modes through script automation through demand analysis, file preparation, first simulation, configuration update, secondary simulation, and result statistics, thereby significantly improving verification efficiency.

[0031] Figure 2 FIG. 1 shows a schematic diagram of a verification system structure provided by an embodiment of the present application. Figure 2 As shown, the verification system includes a compilation and result output module 201 , a file list module 202 to be tested, a SERDES design file module 203 , and a test top-level configuration module 204 .

[0032] Among them, the compilation and result output module (sim) 201 is mainly responsible for running the compilation simulation process. Among them, the compilation simulation script serves as an operating instruction to drive the development of the entire simulation process. During the simulation execution period, the system will generate a simulation log file that records the simulation process information in detail, providing a basis for subsequent backtracking analysis; at the same time, it will also generate a simulation waveform file, which helps debug work by visually presenting signal changes. Specifically, the compilation and result output module 201 dynamically loads the corresponding compilation simulation script according to different test requirements. These scripts clearly specify key parameters such as clock frequency and data rate, and simultaneously control the generation of simulation excitation and the output path of the result file. The compilation and result output module 201 will strictly follow the three steps of compilation (compile), construction design structure (elaborate), and simulation (simulate) to run. In the compilation phase, it checks for code syntax errors, monitors signal changes in real time in the simulation phase, and finally stores the waveform files according to the protocol type classification. For example, the waveform of the PCIe protocol is stored in the pcie_wave directory, and the waveform of the USB protocol is stored in the usb_wave directory. At the same time, a detailed simulation log file will be generated to record warnings and error messages during the compilation process, as well as key events in the simulation process. Finally, the module will automatically analyze the log data, extract key indicators such as bit error rate, functional coverage, timing violations, etc., and generate a structured test report to provide data support for subsequent test result statistics and analysis.

[0033] The file list module (filelist) 202 includes n test required file lists. These file lists clearly list the various files required for the compilation simulation according to different test scenarios, ensuring that the required files can be accurately obtained under different test conditions and that the simulation proceeds smoothly. Specifically, the main work content of the file list module 202 includes three aspects: file list maintenance, dependency checking, and version control. In terms of file list maintenance, the module maintains the corresponding file list according to different test scenarios. Each file list is a text file that fully lists all the file paths required for the current test scenario. For example, in the PCIe protocol test scenario, the file list will include serdes_pcie.v (SERDES design file), top_pcie.v (test top-level file), testbench_pcie.v (test stimulus file), etc.; in the USB protocol test scenario, the file list includes corresponding files such as serdes_usb.v, top_usb.v, and testbench_usb.v. In terms of dependency checking, the module analyzes the dependencies between each file to ensure that all referenced submodule files are included in the file list. If a specific instantiated module is found to have no corresponding file, the module will immediately issue a warning. Regarding version control, the module records the version information of all relevant files before each simulation begins, including key attributes such as file size and last modification time. This ensures that the file versions used in each simulation are consistent, avoiding inconsistent simulation results due to file changes. Furthermore, the module supports dynamic file list updates, allowing for rapid generation of new file lists when test scenarios change, ensuring continuity of verification work.

[0034] The SERDES design file module (testcase) 203 includes the SERDES code files that need to be tested. These files carry the core design content of the SERDES and are the main objects of simulation verification in this embodiment. Accurate testing of them is related to the reliability and stability of the entire SERDES function. Specifically, the SERDES design file module 203 contains the SERDES design code that needs to be verified. This module adopts a layered design architecture and is mainly divided into two parts: the physical medium adaptation layer (PMA) and the physical coding sublayer (PCS). The PMA sublayer is mainly responsible for processing functions related to the physical medium, including high-speed serial-to-parallel conversion circuits, clock data recovery circuits (CDR), pre-emphasis circuits, receive equalization circuits, etc. The serial-to-parallel conversion circuit is responsible for converting low-speed parallel data into high-speed serial data for transmission, or converting received serial data into parallel data; the clock data recovery circuit extracts the clock signal from the received data stream. The PCS sublayer is mainly responsible for functions related to data processing, including 8B / 10B or 64B / 66B encoding and decoding circuits, elastic buffer circuits, channel bonding circuits, and clock correction circuits. The codec circuit is responsible for data encoding and decoding; the elastic buffer circuit is used to compensate for clock domain differences; and the channel bonding circuit achieves multi-channel synchronization. The module adopts a parametric design approach, supporting multiple protocols through macro definitions and parameter configuration. For example, `ifdef PCIE` is used to define parameters specific to the PCIe protocol, and `ifdef USB3` is used to define parameters specific to the USB 3.0 protocol. Each sublayer is connected using standardized interfaces. Interface signals include data bus, clock signal, reset signal, etc. This design allows each sublayer to be modified and verified relatively independently, improving the design's flexibility and maintainability.

[0035] The test top-level configuration module (testbench) 204 is composed of n test top-level files, etc. These files can flexibly respond to the test of various SERDES usage situations by configuring the configuration parameters of different high-speed protocols, and realize comprehensive verification of SERDES functions. Specifically, the test top-level configuration module 204 is responsible for generating corresponding test environments and configuration parameters for different test scenarios. The core functions include three aspects: protocol configuration management, test top-level file generation, and test stimulus control. In terms of protocol configuration management, the module has built-in configuration templates for multiple high-speed protocols, each of which contains the key parameters of the protocol, such as the parameters of the PCIe protocol include link width (x1, x4, x8, etc.), clock frequency (2.5GHz, 5GHz, 8GHz, etc.), encoding mode (8B / 10B, 128B / 130B, etc.); the parameters of the USB3.0 protocol include transmission rate (5Gbps, 10Gbps), encoding mode (NRZ), etc. Regarding test top-level file generation, the module automatically generates the corresponding test top-level files based on the selected protocol configuration. These top-level files instantiate the SERDES design module and configure the correct parameters. For example, when generating the pcie_top.v file, the correct number of channels and clock frequency are set; when generating the usb_top.v file, the corresponding rate and encoding method are configured. Regarding test stimulus control, the module integrates test stimulus generators for various protocols, capable of generating data packets that comply with protocol specifications. For example, for the PCIe protocol, different types of data packets, including TLP and DLLP, can be generated; for the USB protocol, packets such as Token, Data, and Handshake can be generated. The module also supports error injection, inserting error bits or packets that violate protocol rules into the data stream to verify the robustness of the design. Furthermore, the module maintains real-time synchronization with the file list module, ensuring that the test files used at any time fully match the current configuration.

[0036] For example, Figure 3 A flow chart of a SERDES verification method provided in an embodiment of the present application is shown.

[0037] like Figure 3 As shown, the SERDES verification method may include the following steps:

[0038] S31: Collect test requirements, obtain the protocol type and configuration mode supported by the SERDES to be tested, and generate a corresponding first compilation simulation script according to the protocol type.

[0039] In this embodiment, the SERDES configuration mode and function are first analyzed, and various SERDES configuration modes are studied, such as different high-speed protocols (such as PCIe, USB, etc.), data transmission rates, encoding methods, etc., as well as various functions that need to be tested, such as data transmission, clock recovery, channel bonding, etc. According to different configuration modes and function combinations, a special compilation simulation script file is written for each protocol and configuration mode. Each script file corresponds to a specific test scenario to ensure that all possible combinations are covered. The script file includes compilation parameters, simulation stimulus, and result output path. The compilation parameters will affect the synthesis and simulation behavior of the RTL code, such as clock frequency, data rate, protocol type, etc. The simulation stimulus is a test vector used to drive the design file to run and simulate the input signal in the actual scenario. The generation rules of the simulation stimulus can include automatically generating data packets that meet the specifications according to the protocol type, and support injecting error bits or abnormal signals to verify robustness. The result output path is used to indicate that waveform files, log files, etc. are saved to a specified path for subsequent analysis.

[0040] Specifically, the compilation parameters need to be adjusted according to the specific configuration of SERDES. For example, for the PC I e protocol, the clock frequency may be set to 2.5GHz, while for the USB 3.0 protocol, the clock frequency may be set to 5GHz. In addition, the encoding method also needs to be adjusted according to the protocol, such as PC I e uses 8B / 10B encoding, while Ethernet may use 64B / 66B encoding. Simulation stimuli need to be generated according to the protocol and functional requirements. For example, for the data transmission function, the test vector needs to simulate the transmission process of the actual data packet; for the clock recovery function, the test vector needs to include clock jitter and offset to verify the clock recovery capability of the SERDES. The result output path needs to be clearly specified, for example, the waveform file is saved as . / waveforms / simulation_PCI e.fsdb and the log file is saved as

[0041] The log file is . / logs / simulation_PCIe.log for subsequent debugging and analysis.

[0042] S32: Based on the test requirements and protocol type, determine the test top-level file and file list. The file list contains the path of the design file to be tested and the test stimulus file. Check the dependencies of each file to ensure integrity.

[0043] In this embodiment, it is necessary to select a top-level test file and compile a list of required files. After determining the test requirements for the function to be tested, a matching top-level test file is selected. The top-level test file is the top-level layer of the design file to be tested and is used to configure different high-speed protocols and SERDES configuration modes. Because the file to be tested has many configuration modes, a single top-level test file cannot fully test every mode. Therefore, a different top-level test file is required for each test scenario. For example, for the PCIe protocol, the top-level test file may be configured to support 4-channel mode, while for the USB 3.0 protocol, the top-level test file may be configured for single-channel mode. Based on the determined function to be tested, a matching file is selected from multiple top-level test files, for example, "top_10G.v" is selected for 10G Ethernet. In addition, all files required for simulation compilation need to be carefully sorted out and a file list is generated. The file list includes the design file to be tested, the top-level test file, the test stimulus file, etc., to ensure that the required files are accurately obtained in different test scenarios. The generation of the file list needs to be dynamically adjusted according to the test scenario. For example, for PCIe protocol testing, the file list might include serdes_pcie.v, top_pcie.v, and testbench_pcie.v; for USB 3.0 protocol testing, the file list might include serdes_usb.v, top_usb.v, and testbench_usb.v. File list generation can be automated using scripts. For example, a Python script can dynamically generate a file list based on the test scenario and save it as filelist_PCIe.txt or filelist_USB3.txt for subsequent compilation and simulation.

[0044] S33: Call the script, execute the first compilation simulation, and generate a waveform file and a log file. The waveform file records signal timing changes, and the log file records compilation errors, timing violations, and functional coverage.

[0045] In this embodiment, the first compiled simulation script file is run to start the simulation compilation process. During this process, the system performs simulation compilation and generates compilation results. The compilation process includes compiling the RTL code and test stimulus files into an executable simulation model. If an error occurs during the compilation process, the system will generate a compilation log (CompileLog) that records detailed error messages, warnings, and information prompts. The user can modify the code based on the log. If the compilation is successful, the system will enter the simulation phase, run the simulation model, and generate simulation results. The simulation results include a detailed simulation log (Simulation Log) and a waveform file. The simulation log records all events during the simulation process, such as signal changes, assertion check results, coverage data, etc. The waveform file records the time series changes of all signals during the simulation process and can be used for subsequent debugging and analysis. For example, for the simulation of the PCIe protocol, the waveform file may be saved as . / waveforms / simulation_PC I e.fsdb, and the simulation log may be saved as . / logs / simulation_PCIe.log. Users can check the waveform file to see whether the PCS layer of the SERDES performs 8B / 10B encoding correctly or whether the PMA layer recovers the clock signal correctly.

[0046] S34: Switch to the second protocol type, update the test top-level file and file list, and generate a second compilation simulation script.

[0047] In this embodiment, the test files and scripts are updated to adapt to the SERDES test files for the next high-speed protocol. Because SERDES supports multiple protocols and configuration modes, each test scenario requires a different top-level test file and simulation stimulus. Therefore, after completing the simulation of the first test scenario, the top-level test file, file list, and compiled simulation script need to be updated to adapt to the next test scenario. For example, if the first test scenario is the PCIe protocol, the second test scenario may be the USB 3.0 protocol. In this case, the top-level test file needs to be updated from top_pcie.v to top_usb.v, and a new file list filelist_USB3.txt needs to be generated. In addition, the compiled simulation script needs to be updated to ensure that it can correctly compile and simulate the new functions. For example, for the USB 3.0 protocol, the compilation parameters may need to adjust the clock frequency to 5GHz, and the simulation stimulus may need to generate new test vectors to simulate the USB 3.0 packet transmission process. The updated script can be saved as script_USB3.sv and called in batches through automated tools to improve verification efficiency. The file list can be hashed to ensure the consistency of the simulation environment, and file version information is recorded before each simulation.

[0048] S35: Execute secondary compilation simulation to generate a waveform file and a log file corresponding to the second protocol.

[0049] In this embodiment, the updated second compiled simulation script file is executed, the simulation compilation is performed again, and the results including the log file and the waveform file are output. Similar to the first compilation simulation, the system will first compile and generate an executable simulation model. If the compilation is successful, the system will enter the simulation phase, run the simulation model and generate simulation results. The simulation results include simulation logs and waveform files. The simulation log records all events in the simulation process, such as signal changes, assertion check results, coverage data, etc. The waveform file records the time series changes of all signals in the simulation process, which can be used for subsequent debugging and analysis. For example, for the simulation of the USB 3.0 protocol, the waveform file may be saved as . / waveforms / simulation_USB3.fsdb, and the simulation log may be saved as

[0050] The file is . / logs / simulation_USB3.log. Users can view the waveform file to verify that the PCS layer of the SERDES correctly encodes data or that the PMA layer correctly recovers the clock signal. This step is repeated repeatedly until all test requirements are met. During this loop, the compiled simulation script can switch protocol parameters using conditional compilation instructions and supports batch calling of multiple scripts for fully automated verification.

[0051] S36: parse all log files, calculate bit error rate, functional coverage and timing violations, and generate test reports.

[0052] In this embodiment, the system compiles statistics for all simulation test results based on the automatically generated log file and prints the statistical results. The statistics include key indicators such as functional coverage, timing violations, and bit error rate. For example, functional coverage can reflect whether the test covers all configuration modes and function combinations; timing violations can reflect whether the design meets setup / hold time requirements; and bit error rate can reflect the reliability of data transmission. Statistical results can be automatically generated by scripts and saved as test_summary.csv. Users can intuitively understand the overall simulation test situation by viewing the statistical results. For example, if the functional coverage of a test scenario does not reach 100%, additional test vectors are required; if the bit error rate of a test scenario is too high, the design needs to be checked for problems. By using statistical test results, users can quickly locate problems and optimize the design. Printing the statistical results in a clear manner allows users to intuitively understand the overall simulation test situation, such as which test scenarios passed, which had problems, and the links where the problems occurred.

[0053] Figure 4 A simulation verification flow chart provided by an embodiment of the present application is shown. Figure 4 As shown, first compile the code using the RTL code compilation tool. If errors occur, fix the bugs according to the log. If the compilation results are correct, proceed to the next step. Then simulate the code. If the simulation output prints a failure, use the waveform debugging tool to troubleshoot the problem. If it passes, the log prints information about the simulation passing. Continue with the next simulation.

[0054] The above is an introduction to the SERDES verification method provided in the embodiment of the present application. Through modular design and script-driven technology, it effectively solves the problems existing in the traditional verification process, such as complex multi-protocol compatibility verification, low verification efficiency, inconsistent test environment, etc. The solution adopts the method of dynamically generating protocol-specific compiled simulation scripts to support fast switching verification of multiple high-speed protocols such as PCIe, Ethernet, USB, etc.; realizes automated management of the test environment by testing the top-level configuration module and the file list module; introduces file hash verification to ensure the consistency of the test; and uses detailed log analysis and classified waveform storage to improve debugging efficiency. This method significantly improves verification efficiency and coverage, and is suitable for data centers, high-speed network equipment and other fields with strict requirements on communication quality, and provides a systematic solution for the verification of complex SERDES designs.

[0055] It is understandable that the size of the sequence number of each step in the above-mentioned embodiments does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, the steps in the above-mentioned embodiments can be selectively executed according to actual conditions, and can be partially executed or fully executed, which is not limited here. All or part of any features of any embodiment of the present application can be freely and arbitrarily combined without contradiction. The combined technical solution is also within the scope of the present application.

[0056] Based on the methods in the above embodiments, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the methods in the above embodiments.

[0057] Based on the methods in the above embodiments, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the methods in the above embodiments.

[0058] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0059] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0060] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0061] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A SERDES verification method, characterized in that: The method comprises: Collect test requirements, obtain the protocol type and configuration mode supported by the SERDES to be tested, and generate the corresponding first compilation simulation script based on the protocol type. The script contains parameter configurations for clock frequency, data rate, encoding mode, as well as simulation stimulus generation rules and result output path; Based on the test requirements and protocol type, determine the test top-level file and file list, the file list including the path of the design file to be tested and the test stimulus file; Calling the script, executing the first compilation simulation, generating a waveform file and a log file, wherein the waveform file records signal timing changes, and the log file records compilation errors, timing violations, and functional coverage; Switch to the second protocol type, update the test top-level file and file list, generate a second compilation simulation script; perform secondary compilation simulation, and generate a waveform file and log file corresponding to the second protocol; Parse all log files, calculate bit error rate, functional coverage and timing violations, and generate comprehensive test reports.

2. The method according to claim 1, characterized in that The protocol type supported by the SERDES to be tested includes at least one of PCIe, Ethernet, and USB, and the configuration mode includes at least one of data transmission rate, number of channels, and encoding method.

3. The method according to claim 1, characterized in that The waveform files are stored by protocol type, and the log files contain assertion check results and detailed location information of timing violations.

4. The method according to claim 1, wherein The updating test top-level file includes dynamically configuring the encoding mode of the physical coding sublayer PCS and the clock recovery parameters of the physical medium adaptation layer PMA.

5. The method according to claim 1, characterized in that The generation rules of the simulation stimulus include: automatically generating data packets that comply with the specifications according to the protocol type, and supporting the injection of error bits or abnormal signals to verify robustness.

6. The method according to claim 1, characterized in that The file list is hashed to ensure the consistency of the simulation environment, and the file version information is recorded before each simulation.

7. The method according to claim 1, characterized in that The compiled simulation script switches protocol parameters through conditional compilation instructions and supports batch calling of multiple scripts to achieve fully automated verification.

8. A SERDES verification device, characterized in that: Deployed in a verification system, the device includes: The compilation and result output module is used to compile the simulation script as an operation instruction to drive the simulation process; during the simulation execution, the simulation log file is generated, which is used to record the simulation process information; the simulation waveform file is generated, which is used to present the signal changes; The file list module to be tested is used to clearly list the various files required for compilation and simulation according to different test scenarios; SERDES design file module, used to save the SERDES code file to be tested; The test top-level configuration module is used to configure the configuration parameters of different high-speed protocols, cope with the testing of various SERDES usage scenarios, and achieve comprehensive verification of SERDES functions.

Images